180249 2017-12-01 08:32:06 -0800 The GC load balancer should not rely on a global mutex 2017-12-03 14:21:25 -0800 1 1 1 Unclassified WebKit JavaScriptCore WebKit Nightly Build All All NEW P2 Normal --- 180250 1 fpizlo webkit-unassigned gskachkov rniwa oldest_to_newest 1376815 0 fpizlo 2017-12-01 08:32:06 -0800 The Heap::m_markingMutex was a great first attempt at synchronizing a load balancer. It's amazing how long that thing has survived. But profiling shows that this is one of the most (and sometimes the absolute most) contended mutex in WebKit when running Speedometer. 1376816 1 fpizlo 2017-12-01 08:33:10 -0800 @Ryosuke: seems like we have a Speedometer perf opportunity from giving the GC a proper load balancer instead of our current single-global-lock-protecting-a-stack algorithm. If load balancers were like 3D engines, then our GC uses the Wolfenstein 3D of load balancers. I think we can do better. 1377482 2 rniwa 2017-12-03 11:55:59 -0800 I guess it would be useful to know how much wall time is spent in GC during Speedometer. 1377512 3 fpizlo 2017-12-03 14:21:25 -0800 (In reply to Ryosuke Niwa from comment #2) > I guess it would be useful to know how much wall time is spent in GC during > Speedometer. I don’t have a number, but in the past it has responded to GC optimizations and regresssions about the same way as the average of other JS benchmarks. I just got a 1% Speedometer speedup from doing something else to the GC. “Time spent in GC” is not an easily-defined number because the GC is concurrent.