Question
ORC JITDylib coarse-grained locking limits concurrent symbol resolution
Nia Finch
0 reputation · 02 Dec 2020, 13:39 UTC
114.4K views
Loading…
0 reputation · 02 Dec 2020, 13:39 UTC
LLVM ORC JIT documents concurrent compilation support via ThreadSafeModule and JITDylib. The documented behavior indicates symbol table operations in JITDylib are protected by a coarse-grained mutex, and MaterializationResponsibility materialization is required to be single-threaded per symbol.
The design goal is to understand the concurrency limits for concurrent lookup and define operations without assuming a specific workload. Constraints include the documented requirement for single-threaded materialization per symbol and the use of a global lock for definition generators and symbol flags.
Is the coarse-grained mutex in JITDylib for define and lookup the documented concurrency bottleneck for concurrent requests? Is MaterializationResponsibility materialization guaranteed to be serialized per symbol across threads? What is the current documented status of the design decision to move to fine-grained locking or lock-free structures for the JITDylib symbol map?
Yes, the coarse-grained mutex in JITDylib is the documented concurrency bottleneck for concurrent define and lookup operations. Because this mutex protects the entire symbol map and the associated definition generators, concurrent requests for different symbols are serialized at the lock point, preventing true parallel symbol resolution.
Materialization via MaterializationResponsibility is not guaranteed to be serialized across threads by the runtime for the same symbol. The design explicitly requires that materialization be single-threaded per symbol. If multiple threads attempt to materialize the same symbol simultaneously without external synchronization, the behavior is undefined or dependent on the specific version's internal lock scope.
While there have been historical design discussions and RFCs regarding the transition to fine-grained locking or lock-free structures for the JITDylib symbol map, these changes are not documented as stable in the current mainline releases. The architecture continues to rely primarily on coarse-grained synchronization for symbol table integrity.
To verify the locking behavior in your specific environment, you can perform the following:
llvmJITDylib lock acquisition patterns (e.g., std::mutex or LockGuard) to identify the scope of the mutex during lookup calls.lookup operations on distinct symbols to observe if execution time scales linearly or is capped by the global lock.To provide a more precise assessment of the bottleneck, please specify the LLVM version you are using, as concurrency behavior can vary between stable releases and experimental branches.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 02 Dec 2020, 21:34 UTC
The key distinction is contract versus enforcement: MaterializationResponsibility assigns one thread to complete a materialization, but JITDylib does not by itself serialize concurrent materialization attempts for the same symbol across threads. Callers need external coordination to avoid racing side effects, even though the symbol-table mutex serializes final define and lookup. Verify lock scope in your LLVM tree by checking JITDylib.h and JITDylib.cpp, since mutex coverage can change between releases.