Interpreter progress...

Kresten Krab Thorup krab@yl.is.s.u-tokyo.ac.jp
Wed Jul 28 01:43:00 GMT 1999


Tom Tromey <tromey@cygnus.com> writes:

> >>>>> "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.

No, the loader just needs to throw exceptions, but it needs to hold a
lock on the class object while it is being constructed; and thus the
whole class loading thing needs to be packaged in a trampoline-hack.

The interpreter also has to handle this of cause, so likewise, the
main-loop of the interpreter runs in a java trampoline.

> 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?

Right.  My interpreted objects are "binary compatile" with the
compiled ones; the only difference is that a class object for an
interpreted class has some extra fields in the end.  For instance,
from compiled code, you can call a method declared in an
abstract+compiled class, but implemented in an interpreted class.

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

I looked at it briefly, -- it doesn't look too hard.

> 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.

Yes, that's right.  It's a small thing though.

> 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.

That is what I am doing now, and it does indeed work; but the code is
ugly, and it contains too much logic which is a replication of stuff
in the compiler, making it fragile.

BTW, I also found a bug.  java.lang.FirstThread.run() needs to call
_Jv_InitClass on the class object it is calling main() in.  

Kresten

-- 
 Kresten Krab Thorup, Ph.D. Candidate
 c/o Yonezawa Laboratory
 Department of Information Science   
 The University of Tokyo             
 7-3-1 Hongo, Bunkyo-ku, Tokyo 113 Japan
 Fax: +81-(0)3-5689-4365	 
 Phone: +81-(0)3-3812-2111 ext 4118
 Mobile: +81-(0)90-3693-5715


More information about the Java mailing list