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. 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. I hope I made myself clear on why Java needs this patch. 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. Thanks, Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: java-materialize.patch Type: text/x-patch Size: 762 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080418/48c15e64/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: bitcode-reader.patch Type: text/x-patch Size: 1565 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20080418/48c15e64/attachment-0001.bin>
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
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 >