Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: a3bc81f2b56f938615a061ac34779984ec601f7b
https://github.com/WebKit/WebKit/commit/a3bc81f2b56f938615a061ac34779984ec601f7b
Author: Dan Hecht <dan.he...@apple.com>
Date: 2025-03-31 (Mon, 31 Mar 2025)
Changed paths:
M Source/JavaScriptCore/jit/JITWorklist.cpp
M Source/JavaScriptCore/jit/JITWorklistThread.cpp
M Source/JavaScriptCore/jit/JITWorklistThread.h
Log Message:
-----------
[JSC] Fix JITWorklist notify policy logic
https://bugs.webkit.org/show_bug.cgi?id=290760
rdar://148249925
Reviewed by Keith Miller.
Fix two issues with the policy logic guarding notify in
JITWorklist::enqueue():
Problem 1: (benign) race in thread state accounting
There is a window between the end of work() and the next call to
poll() where the mutator will think a notify call is necessary
but it is not because of when the shared state is updated. This is
a benign race (both correctness and perf) because:
Case 1: Number of active threads == Options::numberOfWorklistThreads()
In this case, notifyOne() may be called unnecessarily, but notifyOne() will
internally be a no-op (and avoid syscalls) since no thread is waiting.
Case 2: Number of active threads < Options::numberOfWorklistThreads()
In this case, the notifyOne() will always be called once, either for
an actually waiting thread (there is at least one) or for the racing one,
so the race again doesn't matter.
Though benign, seems worth fixing for clarity, and also to set up for
more sophisticated (auto-)scaling policies where an accurate count does matter.
Problem 2: Unnecessary notifyOne when
m_ongoingCompilationsPerTier[tier] ==
m_maximumNumberOfConcurrentCompilationsPerTier[tier]
Note that on Darwin, the default configuration is:
Options::numberOfWorklistThreads() = 3
Options::numberOfDFGCompilerThreads() = 3
Options::numberOfFTLCompilerThreads() = 3
so this only matters when setting a non-default value.
But in those non-default configurations, if
m_ongoingCompilationsPerTier[tier] ==
m_maximumNumberOfConcurrentCompilationsPerTier[tier]
we shouldn't bother waking up a worklist thread since poll() will do
the m_ongoingCompilationsPerTier check and immediate return the thread
back to waiting.
* Source/JavaScriptCore/jit/JITWorklist.cpp:
(JSC::JITWorklist::enqueue):
* Source/JavaScriptCore/jit/JITWorklistThread.cpp:
(JSC::JITWorklistThread::poll):
(JSC::JITWorklistThread::work):
* Source/JavaScriptCore/jit/JITWorklistThread.h:
Canonical link: https://commits.webkit.org/292951@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
