4 ms·

Hope some knowledgeable people can compare/contrast this with Blink/Servo/Edge etc approach.

by geodel 10y ago

pizlonator 10y ago
You should read the related work section of the post. :-) You can also run the benchmark in Safari Technology Preview 21 and compare it to what you see in the other browsers.
- geodel 10y ago
  You are right. Thanks.
- zbraniecki 10y ago
  that is, if you're on mac, of course. ;)
  - pizlonator 10y ago
    It should be enabled on Linux, so you could build some WebKit-based browser to try it.
the8472 10y ago
It's a non-compacting collector. In principle the downsides compared to compacting collectors is reduced cache locality, fragmentation, somewhat higher allocation overhead and higher memory footprint. On the other hand it is a lot easier to implement concurrent collectors when objects are not moved. > The changes that transformed WebKit’s collector were landed over the past six months, starting with the painful work of removing WebKit’s previous use of copying. It is curious that mozilla chose the opposite, doing the painful work of turning a conservative, non-moving collector into a precise, compacting one.
- BenoitP 10y ago
  > 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!
- pizlonator 10y ago
  > In principle the downsides compared to compacting collectors is reduced cache locality, fragmentation, somewhat higher allocation overhead and higher memory footprint. In actuality the downside of not copying is: - Your allocator has to be tuned to resemble first-fit in its allocation order. This is empirically enough to control memory usage. - You better have more virtual address space than physical address space. This means that the Robson bound for memory usage goes from M log M to M log P where M is memory size, P is page size, and log M or log P is the fragmentation wastage multiplier. People needed compaction really badly back when the state-of-the-art GCs ran on maxed-out 32-bit address spaces. - Mark-sweep collectors have to sweep, copying collectors don't have to. But this is a fixable problem. Sweeping can be made concurrent, parallel, incremental, or very cheap. We pick the very cheap, by using bump'n'pop. Initially we had some regressions from removing copying, but we fixed them by making sure that the first and third mitigation listed above were in place. WebKit rarely runs on a maxed-out 32-bit address space.
espadrine 10y ago
You are listing Web browser engines. This article relates to JavaScript engines (eg: SpiderMonkey (Firefox, Servo), ChakraCore (Edge), V8 (Blink)). V8 has some details about their GC (garbage collector) here[0]; ChakraCore here[1]; SpiderMonkey here[2]. Now, they are all generational, incremental and concurrent, but each with particular tweaks. The approach detailed in this blog post is similar to one taken in ChakraCore, except it sets barriers on fixed-size blocks of memory, while Riptide uses objects. [0]: http://v8project.blogspot.fr/2015/08/getting-garbage-collection-for-free.html http://v8project.blogspot.fr/2015/08/getting-garbage-collect... [1]: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview#garbage-collector https://github.com/Microsoft/ChakraCore/wiki/Architecture-Ov... [2]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Garbage_collection https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Sp...

Hope some knowledgeable people can compare/contrast this with Blink/Servo/Edge etc approach.

by geodel 10y ago

Hope some knowledgeable people can compare/contrast this with Blink/Servo/Edge etc approach.

You should read the related work section of the post. :-) You can also run the benchmark in Safari Technology Preview 21 and compare it to what you see in the other browsers.

geodel 10y ago
You are right. Thanks.
zbraniecki 10y ago
that is, if you're on mac, of course. ;)
- pizlonator 10y ago
  It should be enabled on Linux, so you could build some WebKit-based browser to try it.

the8472 10y ago

It's a non-compacting collector. In principle the downsides compared to compacting collectors is reduced cache locality, fragmentation, somewhat higher allocation overhead and higher memory footprint. On the other hand it is a lot easier to implement concurrent collectors when objects are not moved. > The changes that transformed WebKit’s collector were landed over the past six months, starting with the painful work of removing WebKit’s previous use of copying. It is curious that mozilla chose the opposite, doing the painful work of turning a conservative, non-moving collector into a precise, compacting one.

BenoitP 10y ago
> 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!
pizlonator 10y ago
> In principle the downsides compared to compacting collectors is reduced cache locality, fragmentation, somewhat higher allocation overhead and higher memory footprint. In actuality the downside of not copying is: - Your allocator has to be tuned to resemble first-fit in its allocation order. This is empirically enough to control memory usage. - You better have more virtual address space than physical address space. This means that the Robson bound for memory usage goes from M log M to M log P where M is memory size, P is page size, and log M or log P is the fragmentation wastage multiplier. People needed compaction really badly back when the state-of-the-art GCs ran on maxed-out 32-bit address spaces. - Mark-sweep collectors have to sweep, copying collectors don't have to. But this is a fixable problem. Sweeping can be made concurrent, parallel, incremental, or very cheap. We pick the very cheap, by using bump'n'pop. Initially we had some regressions from removing copying, but we fixed them by making sure that the first and third mitigation listed above were in place. WebKit rarely runs on a maxed-out 32-bit address space.

espadrine 10y ago

You are listing Web browser engines. This article relates to JavaScript engines (eg: SpiderMonkey (Firefox, Servo), ChakraCore (Edge), V8 (Blink)). V8 has some details about their GC (garbage collector) here[0]; ChakraCore here[1]; SpiderMonkey here[2]. Now, they are all generational, incremental and concurrent, but each with particular tweaks. The approach detailed in this blog post is similar to one taken in ChakraCore, except it sets barriers on fixed-size blocks of memory, while Riptide uses objects. [0]: http://v8project.blogspot.fr/2015/08/getting-garbage-collection-for-free.html http://v8project.blogspot.fr/2015/08/getting-garbage-collect... [1]: https://github.com/Microsoft/ChakraCore/wiki/Architecture-Overview#garbage-collector https://github.com/Microsoft/ChakraCore/wiki/Architecture-Ov... [2]: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Internals/Garbage_collection https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Sp...