llvm dev - Jan 2009 - [LLVMdev] IR code generation and JIT execution in a multithread environment

On Jan 12, 2009, at 11:10, Edgar Geisler wrote:
> my goal is to create a service with multiple threads, each of them  
> generating IR code and JIT'ing/executing it in their threads and  
> some threads will share generated code through a code repository...

Hi Edgar,

Module and Value are unsafe for concurrent access--even disjoint  
instances thereof. So you'll need to hold a global mutex while  
loading, building, or transforming IR. The JIT can execute threaded  
code, but itself holds a global lock during code generation.

I think serializing code generation in a JIT will usually be adequate,  
since presumably the compiled program (rather than the compiler)  
should dominate runtime. However, if your project truly needs  
concurrent JIT compilation, LLVM doesn't yet meet your needs. Chris  
Lattner has disclosed an open project at Apple for providing  
multithreaded code generation and IR manipulation, but no code has yet  
hit the repository AFAIK.

You could certainly spawn subprocesses to do concurrent static code  
generation, however.

— Gordon

Quick related Q:
Does the global lock of the JIT during code generation prevent  
concurrent execution of already JIT-ted code?
Thanks.

On Jan 12, 2009, at 9:34 AM, Gordon Henriksen wrote:
> On Jan 12, 2009, at 11:10, Edgar Geisler wrote:
>
>> my goal is to create a service with multiple threads, each of them
>> generating IR code and JIT'ing/executing it in their threads and
>> some threads will share generated code through a code repository...
>
>
> Hi Edgar,
>
> Module and Value are unsafe for concurrent access--even disjoint
> instances thereof. So you'll need to hold a global mutex while
> loading, building, or transforming IR. The JIT can execute threaded
> code, but itself holds a global lock during code generation.
>
> I think serializing code generation in a JIT will usually be adequate,
> since presumably the compiled program (rather than the compiler)
> should dominate runtime. However, if your project truly needs
> concurrent JIT compilation, LLVM doesn't yet meet your needs. Chris
> Lattner has disclosed an open project at Apple for providing
> multithreaded code generation and IR manipulation, but no code has yet
> hit the repository AFAIK.
>
> You could certainly spawn subprocesses to do concurrent static code
> generation, however.
>
> — Gordon
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

Graham Wakefield wrote:
> Quick related Q:
> Does the global lock of the JIT during code generation prevent  
> concurrent execution of already JIT-ted code?
>   
No, it's not related.

Nicolas

Hi Gordon,
> Module and Value are unsafe for concurrent access--even disjoint
> instances thereof. So you'll need to hold a global mutex while
> loading, building, or transforming IR. 
>From my (limited) point of view it would be nice to have some
fine grained lock mechanisms for IR/JIT generation. AFAIK the
critical sections during IR (Module) generation are the alteration 
or access to the static/global Type-/ValueMaps. Wouldn't it be
sufficient to protect them by some kind of 'null'-mutex and leaving the
implemtation to the particular project?
> I think serializing code generation in a JIT will usually be adequate,
> since presumably the compiled program (rather than the compiler)
> should dominate runtime. However, if your project truly needs
> concurrent JIT compilation, LLVM doesn't yet meet your needs. 
I am using LLVM as a kind of glue between a controlling process (exe) and 
some services (lib). Within my mentioned scenario IR/JIT generation
dominates 
runtime with an average factor of 5-10. Simply speaking, executing a
service needs ~ 10 ms while IR/JIT generation for this service needs 
~ 40 - 100 ms on the average. So, if the controller gets a bulk
of service requests, it can be expected that the requests will be lined up
at a global Module generator or at the global JIT generator mutex. 

Edgar