Re:Ada's Dependent Types, and Its Types as a Whole
by fpoling on Saturday December 28, 2024 @08:00AM
(#42530765)
Explicit language support is very nice as the compiler can and do a lot of optimizations and free the space as early as possible on all control paths and ensure full memory safety.
For example, when a function returns a thing on the second stack the compiler can arrange that, before returning, the thing is moved to the second stack position that was at the start of the function. This releases the memory that was used for other things by the callee. Then the caller knows the second stack depth after the call and can release its second stack usage just as well.
Re:Ada's Dependent Types, and Its Types as a Whole
by alexvitkov on Saturday December 28, 2024 @09:20AM
(#42531203)
Doing frees/moves/copies on the second stack makes it harder to track the lifetime of allocations, and restricts what you can use it for - to free a block on the stack you necessarily have to free everything after it.
Most programs have a point where you know nothing on it is used and it's convenient (and very performant) to free the entire thing, and that makes it way easier to reason about - when you alloc from it you know your block of memory it's valid until a <RESET> point:
- For a video game you can <RESET> at the start of every frame
- For a web server you can alloc a new stack for every incoming request and <RESET> after the request is over
- For a short-lived program you may not even need to <RESET> at all
Re:Ada's Dependent Types, and Its Types as a Whole
by toolslive on Saturday December 28, 2024 @03:30PM
(#42534360)
The <reset> point is indeed what you need to look for but
why does it need to be a stack ? I guess it's just a naming thing. I've always looked at it as a scratchpad (that was heap allocated)
Re:Ada's Dependent Types, and Its Types as a Whole
by nmilo on Saturday December 28, 2024 @05:30PM
(#42535395)
You can just pop the second stack at each function return, though that does limit its use to only really scratch-space for dynamically sized objects. Like this: https://nullprogram.com/blog/2023/09/27/. “Arenas” are passed by value so their end pointer will auto reset when the function returns.
It's just a static buffer that you can use for temporary allocations, e.g. to return an array of 50 int32's to a parent stack frame you can just allocate `50*sizeof(int32)` bytes on that buffer and return a pointer to the beginning, instead of a heap-allocated `std::vector<int32>`. Every allocation advances the head of the buffer, so you can have multiple allocations alive at the same time.
Every once in a while you need to free the buffer, which just means resetting its head back to the start - in the case of games the beginning of a new frame is a convenient point to do that.
This doesn't solve dynamic memory in general, as it can't be used for long-lived allocations, it just saves you a bunch of temporary heap allocations. It doesn't solve all problems that RAII does either, as RAII is often used for resources other than memory - files, sockets, locks, ...
[1] https://www.rfleury.com/p/untangling-lifetimes-the-arena-all...