[llvm-dev] ORC JIT and multithreading
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Wed Nov 15 07:36:30 PST 2017
On Tue, Nov 14, 2017 at 4:31 PM Lang Hames via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Christian,
> ORC doesn't have any locks internally at the moment. Approach (1) is the
> recommended solution. I'm working on a refactor that should be out in a few
> weeks that will improve threading support, and I expect to put more effort
> into multi-threaded performance in the next few months.
What's the shared state that necessitates (1)? Having a separate
LLVMContext+separate ORC JIT stack (I think that's what's being suggested -
in (2) for example), etc should suffice?
If a whole process can only have one ORC JIT stack that seems really
problematic, and I'd be surprised if that were the case so I guess I'm
> Out of interest, are you saying that approach (1) was a regression
> compared to MCJIT's behavior?
> On Mon, Nov 6, 2017 at 12:28 PM, Christian Schafmeister via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>> How would I go about enabling the ORC JIT to compile code in multiple
>> Some background:
>> I’ve switched Clasp (an implementation of Common Lisp that uses llvm as
>> the backend - github.com/drmeister/clasp) over to using ORC as its JIT.
>> I did this by following the Kaleidoscope tutorial. I have a ClaspJIT_O
>> class that copies the KaleidoscopeJIT class.
>> Clasp is multithreaded and it needs to compile code in multiple threads
>> because it uses the JIT to generate dispatch functions for multiple
>> dispatch/generic functions. To make this possible, every thread gets its
>> own LLVMContext and every type and llvm::Module that is linked into JITted
>> code in each thread is initialized lazily and thread-locally. Despite
>> this - I experience frequent, random crashes when I try to use the ORC JIT
>> from multiple threads.
>> Here’s what I’ve tried:
>> (1) This works: wrap a lock/mutex around access to one ClaspJIT_O
>> object, the calls to ClaspJIT_O::addModule and a call to
>> jitFinalizeReplFunction are protected by the lock:
>> The Common Lisp code that does the lock and calls these functions:
>> This throttles the system and limits one thread at a time to add modules
>> to the JIT and lookup symbols in the JIT. It’s not bad - I can live with
>> (2) This fails: Keep a thread local copy of a ClaspJIT_O object that is
>> lazily initialized as soon as any compilation happens in a thread.
>> (3) This fails: Keep a thread local copy of a ClaspJIT_O object that is
>> initialized as in #2 AND wrap a lock/mutex around ClaspJIT_O::addModule and
>> a call to jitFinalizeReplFunction. What I thought I was testing here was
>> if there was some global resource that ORC uses and despite having multiple
>> thread-local ClaspJIT_O objects the different threads were trampling that
>> common global resource.
>> I can provide many more details on request.
>> Christian Schafmeister
>> Professor, Chemistry
>> Temple University
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev