4 ms·

Good summary! Generational references were less than half the overhead of RC as of last benchmark. [0] Re inline data: A piece of inline data will (most often

Good summary! Generational references were less than half the overhead of RC as of last benchmark. [0] Re inline data: A piece of inline data will (most often) share the generation of its containing object. A generational reference can include an offset to the parent's generation, which we can use for generation checks. Inline data should make it even faster, because then we can control our objects' layouts and use the cache more efficiently, and not be chasing pointers all the time. I think that's the biggest advantage of generational references over RC and GC. We're also building regions into the type system, which can be used to statically temporarily freeze areas of memory (similar to the Rust borrow checker) to eliminate generation checks. [1] Another very experimental aspect we're prototyping is "hybrid generational memory" which can temporarily lock an object (similar to a RefCell) to elide a lot more generation checks [2] but it's too early to promise it will work. [0] https://verdagon.dev/blog/generational-references https://verdagon.dev/blog/generational-references [1] https://verdagon.dev/blog/zero-cost-refs-regions https://verdagon.dev/blog/zero-cost-refs-regions [2] https://verdagon.dev/blog/hybrid-generational-memory https://verdagon.dev/blog/hybrid-generational-memory

azakai 4y ago
> A generational reference can include an offset to the parent's generation I see, thanks for the clarification. Then interior pointers will be larger than normal pointers, like all generational pointers? While the interior object itself doesn't have a generation, avoiding that overhead. Makes sense I think. All the larger pointers do make me worry about increased memory overhead, though (kind of the reverse of the x32 ABI which has half-sized pointers; I think 5-8% is the quoted perf difference there). Do you have benchmarks of memory overhead - looks like the link has throughput? Regardless, it sounds like the other features you mention should help with both forms of overhead, so it will be interesting to see how much. Cool project btw!
- verdagon 4y ago
  Thanks! The increased memory overhead would seem to be a problem, but in the programs I work on at least (games, web servers, compilers), the vast majority of references in a program are owning references which aren't fat pointers. Non-owning references are very short-lived and on the stack, so the memory overhead shouldn be pretty minor in practice. Also, if we want to save a little more space, we can reduce the generations to 32 bits (we're leaning this way in fact, as it opens the door to some interesting other features).
andrepd 4y ago
But 1. This technique prevents undefined behaviour, by halting whenever an invalid dereference is detected. While Rc is a garbage collection algorithm. So you are comparing apples and oranges, no? 2. Rc is a bad gc algorithm. How does this compare to a good quality, generational, incremental gc?

azakai 4y ago

> A generational reference can include an offset to the parent's generation I see, thanks for the clarification. Then interior pointers will be larger than normal pointers, like all generational pointers? While the interior object itself doesn't have a generation, avoiding that overhead. Makes sense I think. All the larger pointers do make me worry about increased memory overhead, though (kind of the reverse of the x32 ABI which has half-sized pointers; I think 5-8% is the quoted perf difference there). Do you have benchmarks of memory overhead - looks like the link has throughput? Regardless, it sounds like the other features you mention should help with both forms of overhead, so it will be interesting to see how much. Cool project btw!

verdagon 4y ago
Thanks! The increased memory overhead would seem to be a problem, but in the programs I work on at least (games, web servers, compilers), the vast majority of references in a program are owning references which aren't fat pointers. Non-owning references are very short-lived and on the stack, so the memory overhead shouldn be pretty minor in practice. Also, if we want to save a little more space, we can reduce the generations to 32 bits (we're leaning this way in fact, as it opens the door to some interesting other features).

andrepd 4y ago

But 1. This technique prevents undefined behaviour, by halting whenever an invalid dereference is detected. While Rc is a garbage collection algorithm. So you are comparing apples and oranges, no? 2. Rc is a bad gc algorithm. How does this compare to a good quality, generational, incremental gc?