Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 1656e50c527a22441a66716538de00c1deb66dc0
https://github.com/WebKit/WebKit/commit/1656e50c527a22441a66716538de00c1deb66dc0
Author: Dan Hecht <dan.he...@apple.com>
Date: 2025-06-30 (Mon, 30 Jun 2025)
Changed paths:
M Source/JavaScriptCore/jit/JITWorklist.cpp
M Source/JavaScriptCore/jit/JITWorklist.h
M Source/JavaScriptCore/jit/JITWorklistThread.cpp
M Source/JavaScriptCore/jit/JITWorklistThread.h
Log Message:
-----------
[JSC] JITWorklist: consider size when determining a JITPlan's expected load
https://bugs.webkit.org/show_bug.cgi?id=295209
rdar://154678309
Reviewed by Yusuke Suzuki.
Currently, a JITPlan's load is determined solely by the tier. But
for really large codeBlocks, the compilation time can be on the same
order as higher tiers. Let's avoid mispredicting the load for these
these outliers by bumping the load for large codeBlocks.
This requires more bookkeeping since each plan in a particular queue
can have a different load, and so total load can no longer be
inferred by queue length. To handle this, maintain a running
total load which is incremented when JITPlans are enqueued and
decremented when they complete compilation or are canceled.
The cancellation case complicates the bookkeeping in a couple of ways:
1. Need to coordinate which thread decrements in the case of cancellation.
a. If the cancellation occurs while the JITPlan is still waiting
in a queue, then the thread driving the cancellation needs to
handle the bookkeeping.
b. Otherwise, cancellation occurred after a compile thread dequeued
the plan and is about to or is compiling the plan. In this case,
the compile thread decrements the load once the cancellation is
processed.
2. Once a JITPlan is canceled, the codeBlock can be dead so cannot
be accessed after that point. But since case 1b occurs asynchronously
some time later, the load cannot be computed at this point. To handle
this, the compiler thread remembers the JITPlan before dropping
the worklist lock during poll, which is the handoff point described
in 1a-b.
The size threshold for outliers is chosen as follows:
Median compilation time and size for each tier:
Baseline: ~15 usec / 90 bytecode instructions
DFG: ~100 usec / 90 bytecode instructions
FTL: ~800-1000 usec / 114 bytecode instructions
At 2000 bytecode instructions, baseline compiles take around
100-200 usec, which is similar to DFG median. At 12000 bytecode
instructions, baseline compiles take 500+ usec which is similar to FTL.
At 2000 bytecode instructions, DFG compiles are around 1000 usec, which
is similar to FTL.
FTL load is always set to 1 thread unit and since a compile of a JITPlan
is single threaded, there's no benefit to adjusting them.
* Source/JavaScriptCore/jit/JITWorklist.cpp:
(JSC::JITWorklist::planLoad):
(JSC::JITWorklist::wakeThreads):
(JSC::JITWorklist::enqueue):
(JSC::JITWorklist::totalOngoingCompilations const):
(JSC::JITWorklist::removeMatchingPlansForVM):
* Source/JavaScriptCore/jit/JITWorklist.h:
* Source/JavaScriptCore/jit/JITWorklistThread.cpp:
(JSC::JITWorklistThread::poll):
* Source/JavaScriptCore/jit/JITWorklistThread.h:
Canonical link: https://commits.webkit.org/296834@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
_______________________________________________
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes
