Skip to content

[JSC] JITWorklist: consider size when determining a JITPlan's expected load #47380

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conversation

dhecht
Copy link
Contributor

@dhecht dhecht commented Jun 30, 2025

1656e50

[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

de351c5

Misc iOS, visionOS, tvOS & watchOS macOS Linux Windows
✅ 🧪 style ✅ 🛠 ios ✅ 🛠 mac ✅ 🛠 wpe ✅ 🛠 win
✅ 🛠 ios-sim ✅ 🛠 mac-AS-debug ✅ 🧪 wpe-wk2 ⏳ 🧪 win-tests
✅ 🧪 webkitperl ✅ 🧪 ios-wk2 ✅ 🧪 api-mac ✅ 🧪 api-wpe
✅ 🧪 ios-wk2-wpt ✅ 🧪 mac-wk1 ✅ 🛠 wpe-cairo
✅ 🛠 🧪 jsc ✅ 🧪 api-ios ✅ 🧪 mac-wk2 ✅ 🛠 gtk
✅ 🛠 🧪 jsc-arm64 ✅ 🛠 vision ✅ 🧪 mac-AS-debug-wk2 ✅ 🧪 gtk-wk2
✅ 🛠 vision-sim ✅ 🧪 mac-wk2-stress ✅ 🧪 api-gtk
✅ 🛠 🧪 merge ✅ 🧪 vision-wk2 ✅ 🧪 mac-intel-wk2 ✅ 🛠 playstation
✅ 🛠 tv ✅ 🛠 mac-safer-cpp ✅ 🛠 jsc-armv7
✅ 🛠 tv-sim ❌ 🧪 jsc-armv7-tests
✅ 🛠 watch
✅ 🛠 watch-sim

@dhecht dhecht requested a review from a team as a code owner June 30, 2025 16:44
@dhecht dhecht self-assigned this Jun 30, 2025
@dhecht dhecht added the JavaScriptCore For bugs in JavaScriptCore, the JS engine used by WebKit, other than kxmlcore issues. label Jun 30, 2025
Copy link
Member

@Constellation Constellation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

r=me

@dhecht dhecht added the safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks label Jun 30, 2025
@webkit-ews-buildbot webkit-ews-buildbot added merge-queue Applied to send a pull request to merge-queue and removed safe-merge-queue Applied to automatically send a pull-request to merge-queue after passing EWS checks labels Jun 30, 2025
@webkit-ews-buildbot
Copy link
Collaborator

Safe-Merge-Queue: Build #61888.

…d 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
@webkit-commit-queue webkit-commit-queue force-pushed the eng/JSC-JITWorklist-consider-size-when-determining-a-JITPlan-s-expected-load branch from de351c5 to 1656e50 Compare June 30, 2025 22:30
@webkit-commit-queue
Copy link
Collaborator

Committed 296834@main (1656e50): https://commits.webkit.org/296834@main

Reviewed commits have been landed. Closing PR #47380 and removing active labels.

@webkit-commit-queue webkit-commit-queue merged commit 1656e50 into WebKit:main Jun 30, 2025
@webkit-commit-queue webkit-commit-queue removed the merge-queue Applied to send a pull request to merge-queue label Jun 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
JavaScriptCore For bugs in JavaScriptCore, the JS engine used by WebKit, other than kxmlcore issues.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants