[llvm-commits] VM hooks when locking
nicolas.geoffray at lip6.fr
Fri Jul 31 11:31:03 CDT 2009
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).
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
More information about the llvm-commits