[llvm-commits] VM hooks when locking

[Nicolas Geoffray]

Hi Chris,

Chris Lattner wrote:
>
> Why do we even need this?  It seems that vmkit has very very specific  
> needs here. 

The need is for precise garbage collection in mulithreaded applications. 
When a collection is triggered, threads must join the collection on 
their own, e.g. poll a global variable regularly to verify that a 
collection is not happening. Threads blocked in native calls, e.g. 
pthread_mutex_lock, just notify the GC before doing the call that they 
won't be able to join the collection. So the GC won't wait for them.

>  Why not have a vmkit lock which is redundant with the  
> llvm lock?  You can wrap the same scope as the JIT and that way you'll  
> know the acquire of the LLVM lock will always succeed.  This way, you  
> only make VMKit more complicated, not all of llvm.  If you need  
> callbacks from the compilation-callback path, that would be very  
> reasonable to add.
>   

So what I'm proposing is a workaround due to the fact that the JIT lock 
is used both for protecting internal data of the JIT (tables), but also 
for creating IR stuff (types, constants, etc), as the code generator may 
create IR stuff. With Owen's changes, hopefully, the logic should be 
more sane and the workaround could be removed.

But OK, I'll see if the workaround can be put in vmkit (which uses the 
JIT lock to protect IR stuff creation).

Thanks,
Nicolas


> -Chris
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>