link to grimoire thing here
If an object is never moved 0 then we can put it on a stack.
Generational memory will have multiple "generational stacks", one for each size class, just like jemalloc and mimalloc have parallel heaps. 1 2 Because of this, and stack-allocated objects' allocation pattern, it will have cache-friendliness similar to a regular stack.
Additionally, when we identify objects that don't need a generation, they can go on the regular stack, not these generational stacks. 3
...or moved only to child calls, and in some cases, only moved to parent calls.
We'll have a stack each for 8b, 16b, 24b, 32b, 48b, 64b, etc. Larger objects will occupy multiple entries.
Each stack will use a free-list because we need to retire a slot in the stack once its u48 generation hits 0xFFFFFFFFFFFF.
For example, an iterator might be owned by one local and never moved, and only hand out references that are guaranteed to not outlive the object, so we can guarantee it doesn't need a generation.
We can support objects containing other objects inline. 4 The only complication is that inline objects are not right after their allocation's generation, as previously assumed. So, we'll:
For example, in C, a struct can live inside another struct's memory, unless it's a pointer.
The generational reference is only the first step towards hybrid-generational memory, and it already beats reference counting.
Hybrid-generational memory adds two layers of optimization:
When hybrid-generational memory is fully realized, we expect it could be as fast as Rust, and almost as fast as C++. 5
We're excited about this, because it gives us raw speed with zero unsafety, and keeps the language easy to learn and use.
See Hybrid-Generational Memory to learn more, and feel free to swing by the discord server with any questions or ideas!
See Hybrid-Generational Memory for some comparison with Rust!