[LLVMdev] Re: Newbie questions

[Tom Tromey]

>>>>> "Vikram" == Vikram Adve <vadve at cs.uiuc.edu> writes:

Vikram> Ok, this makes sense.  But I was actually asking how you deal with
Vikram> this in the LLVM JIT for libgcj (I guess it is too early for you to
Vikram> have an answer).

Yeah.  I completely punted on exception handling in general, since at
the moment there is really no hope for integrating it into libgcj :-(

I did look at writing little trampoline functions for calls into and
out of LLVM-compiled code ... but that still fails when we take stack
traces, and these traces are essential in some situations.

So until this is fixed the JIT for libgcj is more or less an
experimental toy.

Vikram> Specifically, I don't think either of these approaches will be
Vikram> sufficient when using LLVM as a JIT in libgcj.  In either case, an
Vikram> LLVM optimization could still reorder trapping instructions.

I don't know what to do -- you tell me :-)

It sounds like LLVM needs some way for its users to express this sort
of thing.

Vikram> What are your plans for the LLVM JIT?  It would be quite valuable to
Vikram> have a JVM-bytecode front end for LLVM.  At this point, llvm-java
Vikram> development has been suspended for some time and I don't think it
Vikram> makes sense to put effort into two different front-ends if we can
Vikram> avoid it.

I'm going to keep developing it as an add-on for libgcj.
Hopefully I'll be able to distribute it in FC6 or FC7.

Last night I found a huge, glaring bug in my JIT (so huge that I
don't really know how I could have missed it before) that will
require a fair bit of surgery.  I'll be fixing that this week.

Once I've stabilized things a bit I will check in the needed libgcj
patch so that the JIT doesn't require a custom gcc build in order to
be plugged in.

For the time being I'm only interested in having it work in libgcj.
But, I agree, duplicating effort doesn't make sense.  If there's a way
to generalize it to work in other environments, I'm open to it.

Tom