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