[LLVMdev] Function materializing in Java

[Nicolas Geoffray]

Great! The goal is now to make vmkit execute without a patch'ed llvm 
before 2.3.

Nicolas

Chris Lattner wrote:
> 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
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>