[LLVMdev] Function materializing in Java
nicolas.geoffray at lip6.fr
Sun Apr 20 01:38:50 PDT 2008
Great! The goal is now to make vmkit execute without a patch'ed llvm
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.
>> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
More information about the llvm-dev