Re: Interpreter progress...

[Tom Tromey <tromey@cygnus.com>]

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

Kresten> I rewrote the class loader in C++, and that cleaned it up
Kresten> quite nice.

Does the class loader ever have to catch exceptions?  (I haven't
looked at it in a while and I don't recall.)  If so, be aware that the
C++ "try/catch" can't catch Java exceptions.  You have to interpose an
ugly bit of code; see hackTrampoline() in java.lang.Class.

Kresten> I'm thinking it would be nice to add a field to _Jv_Method so
Kresten> that the v-table offset is provided by the compiler.  It
Kresten> seems to have a 16-bit alignment gap in it anyway, between
Kresten> the accflags and ncode fields.

I assume you need this because you are constructing your own vtables
on the fly?

Anyway, it seems ok to me.  I'd imagine that the compiler side here is
easy to implement, but I'm not positive.

There is at least one other thing this would clean up in libgcj.
Right now we assume that slot index 1 is the object's finalize
method.  See _Jv_AllocObject in prims.cc.

Actually, it seems to me you can compute the vtable offset on the fly
by using the method pointer in _Jv_Method and comparing it against
existing values in the vtable (which is available via the class).
However, this also seems clunky and ugly; I'd prefer to have the info
directly available.

Kresten> Does some architectures pass 64-bit longs as structures?

I have no clue.  The egcs hackers might.

Kresten> There could be a lot of memory saved, for instance, by
Kresten> uniqing utf8-strings.

This is on our to-do list.  Someday we'll enter this list into Gnats,
so everybody can see it.

This requires linker hacking, and thus gets pushed to the bottom of
the list pretty consistently.

Tom