Re: Interpreter progress...

[Per Bothner <per@bothner.com>]

Kresten Krab Thorup <krab@gnu.org> writes:

> I'm beginning to think, that maybe interpreted classes should have an
> extra vtable that the interpreter can use to call other interpreted
> methods in an efficient way.

I don't think that is the right thing to do.  First note that a class's
vtable can contain a mix of compiled and interpreted methods (if an
interpreted class extends a compiled class), which strongly suggests
that discriminating at the class/vtable level is the wrong approach.
Instead, we must discriminate at the method level:  invokevirtual
must index the vtable to get a method.  For compiled methods, the
elements in the vtable point directly to normal entry points;  for
interpreted methods, the vtable entry is a stub.  What we want is a
way for the interpreter to have a cheap (and reliable) way to tell
which it is, and if the method is interpreted then call "_Jv_EvalMethod"
(or whatever it is called) directly instead of invoking libffi.

Exactly how to determine if a method is interpreted is a bit tricky.
One could have a bit-map in parallel with the vtable.  Or one would
look at the stub itself:  stubs have a very specific layout, starting
with a fixed set of instructions, which may be different from what a
compiler would generate for non-stub functions.   We could artificially
add a magic number to a stub which would be different from any valid
instruction.  (This is of course  easier on a risc machine or other
machine with a fixed instruction length.)  Or we can have gcj emit
a magic number *before* the method address for a pre-compiled function,
and have the interpreter generate a different magic number. 

Once we have determined that a method is interpreted, it should be easy to
extract the method's bytecode given the stub.
-- 
	--Per Bothner
bothner@pacbell.net  per@bothner.com   http://home.pacbell.net/bothner/