3 ms·
An interesting story on generational garbage collectors: a couple of versions ago, Lua experimented with a generational GC. But it didn't improve performance, s
by ufo 7y ago
An interesting story on generational garbage collectors: a couple of versions ago, Lua experimented with a generational GC. But it didn't improve performance, so they kept the old incremental collector. A long time later, they looked at it more closely and realised that the actual problem was that the generational collector was moving objects out of the nursery too eagerly. Objects in the stack are live and will survive if the GC runs, but many of them will stop being live as soon as their function returns. They fixed the issue by making the stack objects that survive one round of GC to stay in the nursery. The new GC is now much faster than the old one, and is one of the big features of the upcoming Lua 5.4
- ridiculous_fish 7y agoInteresting! Is there a more detailed post about this? I wonder how they decide which objects are rooted only by the stack. Is it part of the write barrier, or computed at mark time?
- ufo 7y agoI think it just forces objects to survive more than one collection before moving out of the nursery, without having a special logic for whether they were rooted on the stack or not. But I am not 100% sure so don't quote me on that. https://github.com/lua/lua/blob/6f1c033d72af8fe65bb67e17a242314b6aeb182f/lgc.c#L1133 https://github.com/lua/lua/blob/6f1c033d72af8fe65bb67e17a242...
- cracauer 7y agoWhen using generational GCs it is of utmost importance to match the policies for moving things between GCs to the actual pointer interconnection pattern. This can go really bad, for example in systems that keep caches/repositories of preallocated things for faster re-use. If they are anchored at global variables, or near global, then you need to treat those preallocated things special. You can't just go and move them every time even when knowing you will never collect them. Generally, GC works better if you don't do tricks/optimizations with memory allocation and let just everything flow freely into the heap. If you do have to optimize allocation you generally have to teach your GC about your hack.
- hinkley 7y agoOne of the consequences of this being that when you do in-process caching, you trade improved average case performance for degraded worst-case behavior, unless the GC authors have taken some pains to deal with pointer chasing on writes to the old generation. I'm kind of a fan of out-of-process, same-system caches for this reason.