[LLVMdev] Function materializing in Java

[Chris Lattner]

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.

Ok

> 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.

-Chris