3 ms·

Generational References is quite a neat trick, obvious in hindsight! I assume that the general idea is that non-owners really only have "weak" references (and s

Generational References is quite a neat trick, obvious in hindsight! I assume that the general idea is that non-owners really only have "weak" references (and safety comes from the compiler warning/checking that this isn't broken). One thing though about them is that I assume the generation to be co-located with the memory? If so, then the runtime wouldn't be able to free memory back to the OS while running? (Unless implemented with a side-lookup but that would hamper runtime performance?)

verdagon 4y ago
Askin' the right questions! The generations are colocated with the objects, and we can release memory back to the OS using the virtual memory shenanigans explained in [0]. However, the design and implementation have simplified quite a bit since that article. Now: * We use these generations only for assertions on dereferencing non-owning references, and don't use them for weak references anymore. * We let malloc release memory back to the OS like normal. If the user dereferences something in a released page, we'll get a page fault instead of an assertion failure, but both are handled the same. * When the generation hits INT_MAX, we just let it overflow now instead of blacklisting the allocation forever. These adjustments mean we never need the heap which is a big improvement, and really unlocks Vale as a systems programming language. The purposeful overflowing does mean that only 99.99999998% of invalid memory accesses will halt the program, which is more than enough certainty in practice [1]. (The probability is actually higher, as we increment generations by prime numbers and won't even hit our first possible collision until well after most runs have ended.) [0] https://lobste.rs/s/sglvcc/generational_references_2_3x_faster_than#c_gqakeg https://lobste.rs/s/sglvcc/generational_references_2_3x_fast... [1] https://www.anandtech.com/show/16759/sponsored-post-keep-your-apps-memory-safe-with-arm-memory-tagging-extension-mte https://www.anandtech.com/show/16759/sponsored-post-keep-you...
- kaba0 4y ago
  I really like the ideas behind Vale, but I don’t understand this: “These adjustments mean we never need the heap which is a big improvement” Why would the heap be problematic? It is not different from the stack, there is nothing different between the stack and the heap from the perspective of the CPU. Memory locality is what matters - if you allocate an arena and fill it tightly and refer to elements in it in a predictable manner it will be just as fast.

verdagon 4y ago

Askin' the right questions! The generations are colocated with the objects, and we can release memory back to the OS using the virtual memory shenanigans explained in [0]. However, the design and implementation have simplified quite a bit since that article. Now: * We use these generations only for assertions on dereferencing non-owning references, and don't use them for weak references anymore. * We let malloc release memory back to the OS like normal. If the user dereferences something in a released page, we'll get a page fault instead of an assertion failure, but both are handled the same. * When the generation hits INT_MAX, we just let it overflow now instead of blacklisting the allocation forever. These adjustments mean we never need the heap which is a big improvement, and really unlocks Vale as a systems programming language. The purposeful overflowing does mean that only 99.99999998% of invalid memory accesses will halt the program, which is more than enough certainty in practice [1]. (The probability is actually higher, as we increment generations by prime numbers and won't even hit our first possible collision until well after most runs have ended.) [0] https://lobste.rs/s/sglvcc/generational_references_2_3x_faster_than#c_gqakeg https://lobste.rs/s/sglvcc/generational_references_2_3x_fast... [1] https://www.anandtech.com/show/16759/sponsored-post-keep-your-apps-memory-safe-with-arm-memory-tagging-extension-mte https://www.anandtech.com/show/16759/sponsored-post-keep-you...

kaba0 4y ago
I really like the ideas behind Vale, but I don’t understand this: “These adjustments mean we never need the heap which is a big improvement” Why would the heap be problematic? It is not different from the stack, there is nothing different between the stack and the heap from the perspective of the CPU. Memory locality is what matters - if you allocate an arena and fill it tightly and refer to elements in it in a predictable manner it will be just as fast.