Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 999f58f9729e3aa231845beb8e3f287efc60db99
https://github.com/WebKit/WebKit/commit/999f58f9729e3aa231845beb8e3f287efc60db99
Author: Yusuke Suzuki <ysuz...@apple.com>
Date: 2025-09-15 (Mon, 15 Sep 2025)
Changed paths:
M Source/JavaScriptCore/wasm/WasmBBQPlan.cpp
M Source/JavaScriptCore/wasm/WasmCalleeGroup.cpp
M Source/JavaScriptCore/wasm/WasmCalleeGroup.h
M Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp
M Source/JavaScriptCore/wasm/WasmOMGPlan.cpp
M Source/JavaScriptCore/wasm/WasmOperations.cpp
Log Message:
-----------
[JSC] Do not take CalleeGroup lock for tiering up
https://bugs.webkit.org/show_bug.cgi?id=298802
rdar://160499361
Reviewed by Yijia Huang.
We are taking a lock to get a callee from CalleeGroup. This is weird
since the compiler can just publish it and we can read it concurrently.
The reason why we are doing so is,
1. Let's say, a new BBQCallee (OMGCallee) is compiled.
2. The new callee is linking its direct calls to the other callees. This
includes call to itself! Thus, we need to register itself into
CalleeGroup to allow looking up itself for recursion. However, this
means that now CalleeGroup is having half-baked callee.
3. After (2), the callee is initialized now. But still instruction cache
is not flushed, so we cannot use it yet.
4. We collect calls to this callee, and then flush the instruction cache.
After that, this callee is usable.
5. Then we start liking the other callees' calls to this newly compiled
callee. So random code starts using this newly installed callee.
6. Now, the installation is done.
The problem is coming from (2). Because we install half-baked Callee
into CalleeGroup, if we read it concurrently and start using it, then we
will hit a crash since direct calls are not linked correctly yet.
Since only the problem of (2) is just installing itself to the
CalleeGroup in a half-baked state, let's have staging phase instead.
This patch adds m_currentlyInstallingOptimizedCallees and
m_currentlyInstallingOptimizedCalleesIndex. When linking direct calls,
we read this information and use this half-baked callee. However, when
reading CalleeGroup concurrently for tiering up, we ignore this staging
callee. This allows the main thread to peek compiled Callee concurrently
without taking CalleeGroup::m_lock, which has significant lock
contension.
We also introduce m_bbqCalleeLock to protect m_bbqCallee
ThreadSafeWeakOrStringPtr access since this pointer itself is not
thread-safe, we should protect it from concurrent access. But this lock
is per Callee, so it is not having lock contension. We take this lock
only when we need to access to ThreadSafeWeakOrStringPtr.
* Source/JavaScriptCore/wasm/WasmBBQPlan.cpp:
(JSC::Wasm::BBQPlan::work):
* Source/JavaScriptCore/wasm/WasmCalleeGroup.cpp:
(JSC::Wasm::CalleeGroup::tryGetReplacementConcurrently const):
(JSC::Wasm::CalleeGroup::tryGetBBQCalleeForLoopOSRConcurrently):
(JSC::Wasm::CalleeGroup::releaseBBQCallee):
(JSC::Wasm::CalleeGroup::tryGetOMGCalleeConcurrently):
(JSC::Wasm::CalleeGroup::startInstallingCallee):
(JSC::Wasm::CalleeGroup::finalizeInstallingCallee):
(JSC::Wasm::CalleeGroup::installOptimizedCallee):
(JSC::Wasm::CalleeGroup::updateCallsitesToCallUs):
(JSC::Wasm::CalleeGroup::calleeIsReferenced const):
(JSC::Wasm::CalleeGroup::ensureOptimizedCalleesSlow):
(JSC::Wasm::CalleeGroup::tryGetBBQCalleeForLoopOSR): Deleted.
* Source/JavaScriptCore/wasm/WasmCalleeGroup.h:
* Source/JavaScriptCore/wasm/WasmIPIntSlowPaths.cpp:
(JSC::IPInt::jitCompileAndSetHeuristics):
* Source/JavaScriptCore/wasm/WasmOMGPlan.cpp:
(JSC::Wasm::OMGPlan::work):
* Source/JavaScriptCore/wasm/WasmOperations.cpp:
(JSC::Wasm::JSC_DEFINE_NOEXCEPT_JIT_OPERATION):
Canonical link: https://commits.webkit.org/299970@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
