Re: gcj 3.0 post-mortem

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Per" == Per Bothner <per@bothner.com> writes:

Per> In addition to the obvious performance advantage of a JIT, there
Per> is also a debugging advantage, as all call frames (JIT-compiled
Per> and GCJ-compiled) would have the same layout.  It should also be
Per> easier to have gdb work with JIT-compiled rather than interpreted
Per> code.

I think using ORP is a great idea.  I've been wanting to do it for a
while, but I haven't found the time.  There are some infrastructural
improvements we must make before trying this, but they are easy (right
now we have some hacks to let the interpreter store more information
for each method.  ORP support would mean generalizing this -- which
would also be nicer from a cleanliness standpoint).

One question I have is whether the ORP EH code would integrate well
with our EH scheme.  My recollection is that they implemented their
own EH.  As I recall this might be the only real stumbling block; by
and large their JIT is built to ask the VM for information about class
layout, GC approach, etc.  (I also don't know if the current EH scheme
can handle a JIT.  Can we add to the tables dynamically?)

Tom