Vale's Hybrid-Generational Memory

Vale's hybrid-generational memory is a new memory model that aims to combine all the best parts of existing memory strategies: easy as garbage collection, deterministic as reference counting, and as fast as borrow checking. 0

Note that hybrid-generational-memory is not implemented yet, it's still just a design.

There are three ingredients to make hybrid-generational memory work:

• Generational references!
• Static analysis (sometimes referred to as the "automatic borrow checker") that can eliminate generation checks when it knows an object is alive.
• Scope tethering, to keep an object from getting freed when a local has a reference into it.

Start with Generational References

Hybrid-generational memory is built upon generational references. Recall:

• Every heap allocation has a u4812 generation number before the object.
• Non-owning references contain a raw pointer and a u48 "target generation" number. 3
• Before dereferencing an object, assert that the target generation number matches the allocation's generation number.

Static Analysis: Eliminate Most Liveness Checks

Use static analysis to reduce the number of liveness checks as much as possible. For example:

• For each dereference, figure out if an in-scope local indirectly owns it. If so, skip the liveness check. For more on this, see HGM Static Analysis, Part 1.
• Automatically track this information through intermediate stores/loads from struct members, where possible.
• Automatically track this information through function calls like an automtic borrow checker, where possible.

This static analysis only works when a nearby local holds the owning reference. The scope tethering explained further below will make it work with non-owning locals too.

Add Scope Tethering

The above static analysis only worked when a nearby local holds the owning reference. Now we'll make it work when a nearby local holds a non-owning reference too.

We'll add a u1 "tethered" bit to every allocation, next to the u48 generation number. A local with a non-owning reference can set this bit to 1 to keep its allocation alive. 4 Inside the scope of the local, we can skip all generation checks.

• When the object is allocated, the tethered bit will be 0.
• When a local wants to delay the object's destruction, it will:
• Do a generation check, to see if the object is still alive. If live, load the pointer to the object, otherwise load null. 5
• Save the old value of the tethered bit. 6
• Write a 1 to the tethered bit.
• When the local goes out of scope, it will:
• Write the old value back to the tethered bit.
• When the object is deallocated, if the tethered bit is 1, we'll add it to a queue to check later. 7

Not every non-owning local will tether. Static analysis will make a non-owning tether when it's dereferenced several times. Otherwise, it will just allow the generation checks to happen.

That's basically it! There are some more things we could do to speed it up even more, using virtual memory, regions, or more static analysis, but we'll stop the explanation here.

Minor Extra Details

To address some frequently asked questions:

• When we move something across thread boundaries, we must recurse through 8 and:
• Assert each tethered bit is zero; assert that there are no locals pointing at the object.
• Increment each generation number, effectively cutting off access to the rest of this thread.
• When a generation number hits the maximum, don't use that generation number anymore.
• genFree could slice up the allocation into smaller ones that don't include the initial 8b.

Potential Weaknesses

Some potential weaknesses to explore:

• Storing the generation number at the top of a <=64b allocation means a liveness check won't incur an extra cache miss since we're about to dereference the object anyway, and the entire object is on one cache line. However, for larger objects, it does incur an extra cache miss. Most objects are small, but programs with an unusually large proportion of medium sized objects not in an array could suffer a small performance hit.
• Adding the offset to every reference could interfere with optimizations. If so, we'll have to write our own LLVM pass. 9
• In environments without virtual memory 10, memory fragmentation could be worse, because we can't give pages back to the OS. This is mitigated by regions, where region-calling can guarantee no references pointing into a certain region. 11