Hacker News new | ask | show | jobs
by cracauer 2393 days ago
When 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.

1 comments

One 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.