On Apr 23, 2006, at 9:32 PM, Archie Cobbs wrote:> Chris Lattner wrote: >>> I think the point of llvm-java was to avoid a JVM. That is, it >>> converts >> llvm-java is the JVM. >>> either Java source or Java bytecode into equivalent LLVM bytecode. I >> llvm-java only supports input from Java bytecode. >>> think the big thing lacking so far are the Java library and >>> support for >> llvm-java uses classpath for it's library. >>> things that LLVM doesn't natively support (threading, >>> synchronization >>> come to mind). If you need more detail, Alkis (author of llvm- >>> java) is >>> going to have to respond. Otherwise, you'll need to take a look >>> at the >>> code. >> It's actually missing quite a bit. It is missing too much to >> support programs that use System.Out, for example. Alkis is >> definitely the person to talk to if you're interested in it. > > Thanks.. I'm actually more interested in what would be involved to > hook up LLVM to an existing JVM. In particular JCVM (http:// > jcvm.sf.net). > JCVM analyzes bytecode using Soot, emits C code, compiles that with > GCC, > and then loads executable code from the resulting ELF files.. given > this > design, using LLVM/modules instead of Soot/GCC/ELF would not be > very much > different, but would allow more cool things to happen.If you're only interested in using LLVM for "cool things" (such as optimization), you could use it directly on the C code you emit. Either way, one issue that you will have to deal with is preserving the behavior of Java exceptions (assuming you care about that). LLVM does not preserve the order of potentially excepting instructions (e.g., a divide or a load). This would have to be handled explicitly, whether you use llvm-java or simply used LLVM on the C code from Soot. I don't know if/how libgcj handles this but Tom may be able to say more about that.> > The main barrier to this idea for me are (besides the usual: > limited time > for fun projects) is understanding how it could work. In > particular, how > would one bridge the C vs. C++ gap. JCVM is written in C, and I > have lots > of C and Java experience, but zero with C++. Dumb question: can a C > program > link with and invoke C++ libraries? Or perhaps a little C++ starter > program > is all that is needed, then the existing code can be used via > extern "C"? > Alternately, if there were Java JNI wrappers, I could invoke > those... Etc. > > -Archie >--Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/
Vikram Adve wrote:> If you're only interested in using LLVM for "cool things" (such as > optimization), you could use it directly on the C code you emit.Yes... though the translation to C loses some efficiency due to "impedance mismatch". More ideal would be to go from bytecode -> LLVM directly (I understand this part has already been done more or less).> Either way, one issue that you will have to deal with is preserving the > behavior of Java exceptions (assuming you care about that). LLVM does > not preserve the order of potentially excepting instructions (e.g., a > divide or a load). This would have to be handled explicitly, whether > you use llvm-java or simply used LLVM on the C code from Soot. I don't > know if/how libgcj handles this but Tom may be able to say more about > that.Right.. I think we'd have to revert to signal-less exception checking for null pointer and divide-by-zero for the time being. But this brings up a good point.. should LLVM have an "instruction barrier" instruction? I.e., an instruction which, within the context of one basic block, would prevent any instructions before the barrier from being reordered after any instructions after the barrier? Then a JVM could use signals and still guarantee Java's "exactness" of exceptions by bracketing each potentially-signal-generating instruction with instruction barriers. Someone must have already invented this and given it a better name. Related idea.. what if all instructions (not just "invoke") could be allowed to have an optional "except label ..."? -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com
On Mon, 24 Apr 2006, Archie Cobbs wrote:> Related idea.. what if all instructions (not just "invoke") could be > allowed to have an optional "except label ..."?This is the direction that we plan to go, when someone is interested enough to implement it. There are some rough high-level notes about this idea here: http://nondot.org/sabre/LLVMNotes/ExceptionHandlingChanges.txt -Chris -- http://nondot.org/sabre/ http://llvm.org/
>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes:Vikram> Either way, one issue that you will have to deal with is preserving Vikram> the behavior of Java exceptions (assuming you care about that). LLVM Vikram> does not preserve the order of potentially excepting instructions Vikram> (e.g., a divide or a load). This would have to be handled Vikram> explicitly, whether you use llvm-java or simply used LLVM on the C Vikram> code from Soot. I don't know if/how libgcj handles this but Tom may Vikram> be able to say more about that. libgcj has two different approaches. On some platforms we generate explicit checks for null pointer dereferences and for division by zero (division is a bit different in that we also have to handle java's special rule for dividing -1 by the minimum integer -- I think most platforms actually call the helper function). On other platforms, we don't generate explicit checks but instead let them signal, and then we have special code in the runtime to turn a signal into an exception. The second part here is that GCC knows about implicitly trapping instructions (the -fnon-call-exceptions flag, which we pass to all compilations for these targets). Tom
On Apr 26, 2006, at 10:45 AM, Tom Tromey wrote:>>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes: > > Vikram> Either way, one issue that you will have to deal with is > preserving > Vikram> the behavior of Java exceptions (assuming you care about > that). LLVM > Vikram> does not preserve the order of potentially excepting > instructions > Vikram> (e.g., a divide or a load). This would have to be handled > Vikram> explicitly, whether you use llvm-java or simply used LLVM > on the C > Vikram> code from Soot. I don't know if/how libgcj handles this > but Tom may > Vikram> be able to say more about that. > > libgcj has two different approaches. > > On some platforms we generate explicit checks for null pointer > dereferences and for division by zero (division is a bit different in > that we also have to handle java's special rule for dividing -1 by the > minimum integer -- I think most platforms actually call the helper > function). > > On other platforms, we don't generate explicit checks but instead let > them signal, and then we have special code in the runtime to turn a > signal into an exception. The second part here is that GCC knows > about implicitly trapping instructions (the -fnon-call-exceptions > flag, which we pass to all compilations for these targets).Ok, this makes sense. But I was actually asking how you deal with this in the LLVM JIT for libgcj (I guess it is too early for you to have an answer). Specifically, I don't think either of these approaches will be sufficient when using LLVM as a JIT in libgcj. In either case, an LLVM optimization could still reorder trapping instructions. In the first approach, this is less likely to occur but is possible. The second approach of course wouldn't work because LLVM doesn't have a notion of implicitly trapping instructions and could merrily reorder such operations. What are your plans for the LLVM JIT? It would be quite valuable to have a JVM-bytecode front end for LLVM. At this point, llvm-java development has been suspended for some time and I don't think it makes sense to put effort into two different front-ends if we can avoid it. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/