BC ABI stuff

Tom Tromey tromey@redhat.com
Fri Aug 13 22:24:00 GMT 2004


Thought I'd send a note on BC ABI status and plans.

The status is, things are going very well -- congratulations to
everybody who has been working on this.

I've been testing by building random parts of eclipse with
-findirect-dispatch.  This has shown a few bugs, but nothing really
major.  We're still missing the verifier, and we still need a new user
flag to indicate "don't try to read dependent classes, and don't
bother warning me about it either", but those things are being worked
on.


I've been reading through the class initialization and preparation
code -- what a mess!  There are conditionals all over, including
ifdefs, based on whether classes are BC, interpreted (if the
interpreter exists), etc.  This isn't a surprise, we've all sort of
ignored the growing mess here over the years.  We finally have a good
opportunity to clean it.

My current plan is to introduce a new C++ class along these lines:

    // This is the base class for all execution engines.
    // Ordinarily each subclass of this is a singleton.  The ones that
    // are shipped with libgcj are instantiated statically.
    class _Jv_ExecutionEngine
    {
     public:

      virtual void unregister (jclass) = 0;
      virtual bool need_resolve_string_fields () = 0;
      virtual void verify (jclass) = 0;
      virtual void *resolve_method (_Jv_Method *, jclass, jboolean, jint) = 0;
      virtual void allocate_static_field (jclass, int) = 0;
    };

(The current methods are all ad hoc based on reading through code,
consider this very preliminary.)

Then we'd have subclasses for old ABI code, BC code, and interpreted
code.  We'd add a field to each class pointing to its execution
engine, and the preparation code would be streamlined, with virtual
calls to the engine when needed.

We could handle the code in VMClassLoader.defineClass() by walking
the list of installed engines, asking each if it can handle the class
in question.

This approach is also easily extensible, for instance if we wanted to
plug in a JIT.

Anyway, ideally I would like to have all the `#ifdef INTERPRETER' code
segregated in a file or two, with no other #ifdefs on that in the
source (this is definitely achievable).  I also want to get rid of
duplication between natClassLoader.cc and resolve.cc, eliminate weird
things like different preparation routes for different classes,
_Jv_PrepareCompiledClass which is actually called for all classes,
etc.

Tom



More information about the Java mailing list