Bug 180249
| Summary: | The GC load balancer should not rely on a global mutex | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Filip Pizlo <fpizlo> |
| Component: | JavaScriptCore | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | gskachkov, rniwa |
| Priority: | P2 | ||
| Version: | WebKit Nightly Build | ||
| Hardware: | All | ||
| OS: | All | ||
| Bug Depends on: | |||
| Bug Blocks: | 180250 | ||
Filip Pizlo
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.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Filip Pizlo
@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.
Ryosuke Niwa
I guess it would be useful to know how much wall time is spent in GC during Speedometer.
Filip Pizlo
(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.