Hacker News new | past | comments | ask | show | jobs | submit login

I understood it as that their collector used to be precise, moving and they turned it into a partially-conservative, non-moving one.



Clarification: our previous collector did conservative root scanning, used a less evolved mark-sweep system for some objects, and used a Bartlett-style of quick-release compaction for other objects.

Riptide removes the copying because concurrent or event incremental copying is sure to introduce overhead. Are a minimum you either need a barrier on all pointer reads from the heap or all writes to the heap, and none of those barriers resemble our old generational barrier so this would be new overhead. Riptide only barriers writes of pointers to the heap, and uses a single unified barrier for both concurrency and generations to get maximum throughput. Riptide's concurrency actually improves end-to-end execution time because the overhead of the concurrency is negligible so you just get to enjoy the benefit of continuing to run while the GC runs, so you run faster overall. The speed-up was like 5% on the splay test, and I measured speed-ups in other things I cared about, like page load times.


It still does conservative root scanning for the stack. Hurrah for ABI compatibility!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: