Interpreter progress...

[Kresten Krab Thorup <krab@gnu.org>]

So,

Now I have the basics of an interpreter up and running.  That is, I
can load and execute some non-trivial code, calling forth and back
between compiled and interpreted code, creating objects, etc.  Class
loading, resolving and initialization seems to work, and the basics of
the security checks are in there.  I have not integrated the verifier
with this as of yet, and I'm sure there are still lots of bugs.

There are also things I'd like to improve; now that I have "the big
picture".  I rewrote the class loader in C++, and that cleaned it up
quite nice.  The interpreter-proper is still in it's first
iteration,...

There are some special cases of class-loader checks that I have not
implemented.  Here is an example: When defining a subclass, and the
subclass has a different loader than its super class, one has to
impose class-loader constraints, asserting that any class-name
referred to in a signature of the subclass (and thus potentially
loaded by the subclass' loader) represents the same jclass object, as
if loaded by the super-class' class loader.  These are some pretty
expensive checks.

In fact, you can reasonably imagine several levels of verification.
Right now, for instance, all method and field names are being checked
if they are "valid java identifiers"..  One could imagine applications
in which this would not be necessary to check :-)

One issue, which has been particularly annoying, is that I have to
compute v-table offsets; and it's quite a bunch of ugly code trying to
reverse engineer how the compiler lays out the methods; depending on
if they are private or final, and if they were declared in the
superclass, and the like.  I'm thinking it would be nice to add a
field to _Jv_Method so that the v-table offset is provided by the
compiler.  It seems to have a 16-bit alignment gap in it anyway,
between the accflags and ncode fields.  How does that sound?

I'm using gffi for all stubs and calls; I've rewritten the i386
machine specification (for gffi), so now I hold the copyright for the
whole thing.  The trouble is then, that it *only* works on i386.  I've
changed gffi making it a bit simpler by taking out support for
structure argument passing since it's not needed for Java. (I suppose!
Does some architectures pass 64-bit longs as structures?)  Anyway, as a
result, it's quite easy to write a new machine description.  This
whole thing is a problematic issue though, I'd much prefer if libffi
supported making stubs.  I also had to fix a bug in egcs/c++, the
compiler generated declaration for __builtin_apply was wrong.

There could be a lot of memory saved, for instance, by uniqing
utf8-strings.  (This goes for the compiler as well)...  We did a lot
of work on reducing footprint for Objective-C when I was at NeXT, and
linker-supported string uniqing was an important part of that.  All
these performance issues can be considered later I suppose...

Anyway, I just thought you'd like to know about the progress.  

-Kresten