Rust 1.61.0 released

Posted May 24, 2022 15:17 UTC (Tue) by Wol (subscriber, #4433)
In reply to: Rust 1.61.0 released by excors
Parent article: Rust 1.61.0 released

Provided an item doesn't outlive the function that creates it, does Rust have the equivalent of alloca? Create it in the local stack of the function that wants it, and it goes out of scope with said function?

Or have I completely mis-understood the problem space (not unlikely :-)

Cheers,
Wol

Rust 1.61.0 released

Posted May 24, 2022 15:25 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

The default is to put things on the stack. Or do you mean being able to do something like `[u8; some_local_size]`? I don't think that's possible (the size must be constant evaluated). I think the closest you can get is:

```
let mut _buf = [u8; MAX_SIZE]; // Don't use directly.
let buf = &mut _buf[0..local_size]; // Get a local view into the buffer.
```

But this will always use the maximum size. Note that there are likely perf issues when using something like this that has an `impl Drop` (though maybe `Option<T>` assuming it doesn't take up more room could help elide things there?).

Or course, there is always the possibility that there is some solution that I haven't come across.

Rust 1.61.0 released

Posted May 26, 2022 8:15 UTC (Thu) by NYKevin (subscriber, #129325) [Link] (3 responses)

alloca is formally unsafe, unless you can statically prove that the size you are allocating is "reasonable" for some implementation-defined value of "reasonable." But then you can just use a regular stack allocation of the maximum possible size, which should be cheap or free since that size is "reasonable" and all you're really doing is bumping the stack pointer a bit. The downside, I suppose, is that you ephemerally use some extra memory on the stack, which might result in your stack growing larger than it strictly needs to be (assuming your OS dynamically grows the stack, which AIUI is standard on all modern OS's). But that's a wildly fictional concern, because an alloca as small as a few megabytes can easily blow out the stack all by itself. Relative to the system's memory as a whole, we're talking about very small allocations in the first place, and you're not realistically going to care if your stack is a few hundred KiB larger than it's "supposed to" be, unless you're working on some hilariously resource-constrained embedded device (at which point you probably don't even have an OS in the first place), or you're doing something ridiculous like spawning thousands of threads or implementing golang.

TL;DR: If it's small enough that alloca is safe, you can almost always get away with just using the max size, with little to no downside. If it's large enough that that's a bad idea, then it's also large enough that you can't use alloca and should put it on the heap instead. Therefore, it is not totally unreasonable for a language such as Rust to look at this feature and say "Why bother?"

Rust 1.61.0 released

Posted May 26, 2022 10:09 UTC (Thu) by farnz (subscriber, #17727) [Link] (2 responses)

FWIW, in the last 25 years, I've only seen one form of fully justified use of alloca, which is solved by other means in Rust and C++: you use it on "big" systems (ones with stack expansion in the OS) as a way to avoid leaking memory that you know becomes invalid to access at the end of this function. Effectively a way of guaranteeing that regardless of the path through the code, the allocation is freed when no longer in use - which is guaranteed by std::unique_ptr in C++, and by Box in Rust.

Every other use I've seen of alloca has been trivially replaced by a fixed-sized stack allocation - which had the advantage in my embedded days of allowing the compiler to detect statically that we would overflow our stack if we actually used the full allocation.

Rust 1.61.0 released

Posted May 27, 2022 9:00 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (1 responses)

> "big" systems (ones with stack expansion in the OS)

According to ulimit -s, on my Debian (WSL) system, the stack size maximum is 8 MiB, which has to accommodate the entire stack and not just your frame. I assume this value corresponds to getrlimit(2)'s RLIMIT_STACK value, but I'm not writing a whole C program just to check. Given that the rlimit is adjustable, it's entirely possible that some sysadmin has decided to give you a hilariously small stack and you can't actually grow, even if the architecture and OS are fully capable of supporting dynamic stack growth. The net effect of this is that alloca is not actually safe unless the object is tiny, or at least reasonably small, and is in no way a good general-purpose substitute for std::unique_ptr or the like. If you want to ensure that all code paths lead to free, you basically have to use gotos, or a language other than C.

Rust 1.61.0 released

Posted May 27, 2022 14:19 UTC (Fri) by farnz (subscriber, #17727) [Link]

That's the default, yes, but when you're configuring a system for a use case, you can change it. And that was exactly what I saw done - the system was a "big " system for its era, with 256 MiB RAM, and the rlimit increased to 256 MiB so that actually hitting stack overflow meant you were swapping anyway.

It was also surprisingly portable - at the time (1990s), most system administrators would obey the instruction to increase rlimits to match the software the system was bought to run. Nowadays, I expect most sysadmins would be a lot more cautious about obeying that sort of demand.