[LLVMdev] Function materializing in Java
sabre at nondot.org
Sat Apr 19 17:01:22 PDT 2008
On Apr 18, 2008, at 1:40 PM, Nicolas Geoffray wrote:
> Hi everyone,
> I would like to apply the following patch (java-materialize.patch)
> in order to materialize Java functions in vmkit. The current
> implementation is not satisfactory because the materializeFunction
> of a module provider is not supposed to do anything but read the
> bitcode, which is not the case in Java. In Java, materializing a
> function Foo can possibly trigger class loading (hence executing
> Java code), do static initialization of classes that may even invoke
> Foo. Hence after materializing a function, it's possible that the
> function has already been codegen'd.
> So that's the first part of the patch: after materializing a
> function, the JIT checks if the function has already been codegened.
This is fine, as is moving the lock in getPointerToFunction.
> The second part of the patch involves multi-threading. Since
> materializing a Java function involves executing Java code,
> synchronizations may occur. And one can imagine a scenario where:
> 1) thread A requires the compilation of a function Bar.Foo, hence
> the LLVM JIT takes its lock and invokes matieralizeFunction on the
> Java module provider. Materializing Foo triggers the execution of
> Java code that will load the class Bar. During class loading, the
> code synchronizes on a object Obj already locked by another thread, B.
> 2) thread B is doing class loading and has locked Obj. It then calls
> a function that needs to be jitted. Since thread A already owns the
> lock of the JIT, thread A and B will be interlocked.
> So the second part of the patch does not take the jit lock before
> materializing a function. The lock is taken after the materialization.
Yeah, this is fine.
> I also provide a patch for the BitcodeReader (the only module
> provider implemented in llvm, right?) in order to be thread-safe.
> Just tell me if you think this should be applied too.
I don't think this should be applied. Sync should be done at a higher
level than in the bitcode reader.
More information about the llvm-dev