4 ms·

> painful work of removing WebKit’s previous use of copying Do I understand correctly that the hard work was done, and this is a regression?

• the8472 10y ago
  I understood it as that their collector used to be precise, moving and they turned it into a partially-conservative, non-moving one.
  • pizlonator 10y ago
    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.
    • olliej 10y ago
      It still does conservative root scanning for the stack. Hurrah for ABI compatibility!