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:
Hybrid-generational memory is built upon generational references. Recall:
Vale has three release modes:
Resilient mode uses hybrid-generational memory.
u48 means a 48-bit unsigned integer.
We chose 48 bits, but we could push it as high as 60 bits if we adjusted the below inlining mechanisms. 48 bits is more than enough though.
And a u16 offset to know where the generation is relative to the object, see generational references.
Use static analysis to reduce the number of liveness checks as much as possible. For example:
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.
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.
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.
Someone letting go of the object's owning reference will still call its destructor, regardless of the tethered bit. If the tethered bit is 1, the destructor will not free the object. Instead, the last tethering local will free the object.
Loading from null is a memory safe operation: it's guaranteed to correctly seg-fault if we load from it.
The old tethered bit will usually be 0, but if another local is tethering the object, it could be 1 already.
Specifically, every time we allocate, we check the front of the queue to see if something's tether has expired, and if so, reuse that object. If not, move it to the back of the queue and ask generational malloc instead. Similar to a free-list!
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.
To address some frequently asked questions:
Similar to how Pony scans all incoming and outgoing objects.
Some potential weaknesses to explore:
Presumably, we would make every generational reference have a pointer to the object, and a target generation number, and a pointer to the current generation. The LLVM pass would eliminate the latter.
Every mainstream OS has virtual memory, but WASM does not.
One day, we could write a compactor for Vale which could also help this, though its probably unnecessary.
Vale aims to bring a new way of programming into the world that offers speed, safety, and ease of use.
The world needs something like this! Currently, most programming language work is in:
These are useful, but there is a vast field of possibilities in between, waiting to be explored!
Our aim is to explore that space, discover what it has to offer, and make speed and safety easier than ever before.
In this quest, we've discovered and implemented a lot of new techniques:
These techniques have also opened up some new emergent possibilities, which we hope to implement:
We also gain a lot of inspiration from other languages, and are finding new ways to combine their techniques:
...plus a lot more interesting ideas to explore!
The Vale programming language is a novel combination of ideas from the research world and original innovations. Our goal is to publish our techniques, even the ones that couldn't fit in Vale, so that the world as a whole can benefit from our work here, not just those who use Vale.
Our medium-term goals:
We aim to publish articles biweekly on all of these topics, and create and inspire the next generation of fast, safe, and easy programming languages.
If you want to support our work, please consider sponsoring us on GitHub!
With enough sponsorship, we can: