[webkit-dev] [Block Pointer] Deterministic Region Based Memory Manager
philippeb8 at gmail.com
Sat Mar 5 21:59:52 PST 2016
Thanks for the references, I will take a look.
But about performance, a GC is perhaps faster for a period of time but
when the collector kicks in we notice a CPU usage spiking for a bit
specially on a embedded box with 1 or 2 processors only.
With block_ptr<> the animation would go smoothly at the same constant
But if you say that would involve a 2x slowdown on the UI thread
regardless then I am surprised.
Anyway I am not sure if I can create a patch within a short period of
will repost it to this mailing list.
On 03/06/2016 12:30 AM, Filip Pizlo wrote:
> I would expect our GC to be much faster than shared_ptr. This shouldn’t
> really be surprising; it’s the expected behavior according to the GC
> literature. High-level languages avoid the kind of eager reference
> counting that shared_ptr does because it’s too expensive. I would
> expect a 2x-5x slow-down if we switched to anything that did reference
> You should take a look at our GC, and maybe read some of the major
> papers about GC. It’s awesome stuff. Here are a few papers that I
> consider good reading:
> Some great ideas about high-throughput GC:
> Some great ideas about low-latency GC:
> Some great ideas about GC roots:
> A good exploration of the limits of reference counting performance:
> Anyway, you can’t ask us to change our code to use your memory manager.
> You can, however, try to get your memory manager to work in WebKit,
> and post a patch if you get it working. If that patch is an improvement
> - in the sense that both you and the reviewers can apply the patch and
> confirm that it is in fact a progression and doesn’t break anything -
> then this would be the kind of thing we would accept.
> Having looked at your code a bit, I think that you’ll encounter the
> following problems:
> - Your code uses std::mutex for synchronization. std::mutex is quite
> slow. You should look at WTF::Lock, it’s much better (as in, orders of
> magnitude better).
> - Your code implements lifecycle management that is limited to reference
> counting. This is not adequate to support JS, DOM, and JIT semantics,
> which are based on solving arbitrary data flow equations over the
> reachability set.
> - It’s not clear that your allocator results in fast path code that is
> competitive against either of the JSC GC’s allocators. Both of those
> require ~5 instructions in the common case. That instruction count
> includes the oversize object safety checks.
> - It’s not clear that your allocator is compatible with JITing and
> can be passed around as bits without calling into the runtime. A
> reference counter needs to do some kinds of memory operations on
> variable assignments. This is likely to be about a 2x-5x slow-down. I
> would expect a 2x slow-down if you did non-thread-safe reference
> counting, and 5x if you made it thread-safe.
More information about the webkit-dev