[Webkit-unassigned] [Bug 180250] New: Reduce lock contention in the GC

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=180250

            Bug ID: 180250
           Summary: Reduce lock contention in the GC
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: JavaScriptCore
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: fpizlo at apple.com

We see a lot of lock contention when running Speedometer.  Here are the "hottest" stacks for lock contention.  100% would mean that all lock contention is due to this stack.  It doesn't say anything about how much wall clock time is lost due to lock contention.  Still, it stands to reason that we could get better scalability if we didn't have lock contention, and better scalability means more speed.  We know that the GC got 2x faster going from 1 core to 4 cores, and not much more faster when going to 8.  We also know that scalability at 8 cores improved when we switched to faster locks.  Therefore, I bet if we get rid of locks altogether on those paths that currently see contention, we could probably make the GC significantly faster on tests we care about.

The funniest of these is the addUnconditionalFinalizer contention.  That's just silly.

Top #1 stack: 37.350352%
1   0x1e58b380c WTF::LockBase::lockSlow()
2   0x1e5379b71 JSC::SlotVisitor::addUnconditionalFinalizer(JSC::UnconditionalFinalizer*)
3   0x1e564400f JSC::InferredValue::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)
4   0x1e537d784 JSC::SlotVisitor::drain(WTF::MonotonicTime)::$_3::operator()(JSC::MarkStackArray&) const

Top #2 stack: 15.807631%
1   0x1e58b380c WTF::LockBase::lockSlow()
2   0x1e537919c JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)
3   0x1e535e79e WTF::SharedTaskFunctor<void (), JSC::Heap::runBeginPhase(JSC::GCConductor)::$_11>::run()
4   0x1e58c27ec WTF::ParallelHelperClient::runTask(WTF::RefPtr<WTF::SharedTask<void ()> >)

Top #3 stack: 11.111652%
1   0x1e58b380c WTF::LockBase::lockSlow()
2   0x1e5379b71 JSC::SlotVisitor::addUnconditionalFinalizer(JSC::UnconditionalFinalizer*)
3   0x1e4f20f09 JSC::CodeBlock::visitChildren(JSC::SlotVisitor&)
4   0x1e537d784 JSC::SlotVisitor::drain(WTF::MonotonicTime)::$_3::operator()(JSC::MarkStackArray&) const

Top #4 stack: 7.691025%
1   0x1e58b380c WTF::LockBase::lockSlow()
2   0x1e1d65749 WebCore::Node::eventTargetDataConcurrently()
3   0x1e1d4b0e7 WebCore::EventTarget::visitJSEventListeners(JSC::SlotVisitor&)
4   0x1e16ddcf2 WebCore::JSNode::visitChildren(JSC::JSCell*, JSC::SlotVisitor&)

Top #5 stack: 6.980218%
1   0x1e58b380c WTF::LockBase::lockSlow()
2   0x1e529c071 bool WTF::ConditionBase::waitUntil<WTF::Lock>(WTF::Lock&, WTF::TimeWithDynamicClockType const&)
3   0x1e53792a1 JSC::SlotVisitor::drainFromShared(JSC::SlotVisitor::SharedDrainMode, WTF::MonotonicTime)
4   0x1e535e79e WTF::SharedTaskFunctor<void (), JSC::Heap::runBeginPhase(JSC::GCConductor)::$_11>::run()

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171201/6ec10880/attachment.html>