From: Tim Wilkinson (tim@transvirtual.com)
Date: Tue Sep 15 1998 - 01:26:13 EDT
My thought below ....
Archie Cobbs wrote:
> [Stuff deleted]
> Ideally, clearly defined API's would allow GCJ and Kaffe to continue
> to develop semi-independently yet still remain compatible with an
> already agreed-upon common interface.
>
> Kaffe+GCJ+Klasses.jar+Etc is already starting to get too monolithic.
There's an attempt by the Classpath mob to do something like this by defining a
VMAPI so their classes are potable to any JVM supporting it. I don't know how
far they've
got with this idea as yet.
However, as regards GCJ, it'd be difficult to generate GCJ code which would run
on
any VM without wasting memory. GCJ generates internal class, method and field
records which should match those of the hosting VM so you can simply load in the
shared library and off you go - no parsing and wasting of memory that takes. Of
course
you could parse these structures and convert them but that defeats at least some
of
GCJ's purpose (though not all of course). I've had to make a few patches go my
GCJ
version so these internals match Kaffe's internals (it's close 'cause Cygnus are
using
an old version of Kaffe with a few minor changes).
> So, just thinking about some of the blobs and what API each would export..
> this is just random babble/brainstorming...
>
> JVM - implements JVM Internal interface (JVMII)
> -----------------------------------------------
> - The "guts" of the JVM, including:
> - Memory management
> - Synchronization primitives
> - Thread management
> - Management of ClassLoaders and Classes, but does *not* include
> code to actually execute methods.
> - Implementations of all "system" native methods (yeild(), read(), etc).
> These routines are defined as part of the API.
> - Supports specifying the "internal class handler" at startup time
> (see next blob).
> - This is like today's kaffe minus the JIT/interpeter
> - (Someday) Implements the Java debugging interface
I keep thinking about pulling out the execution engines from the runtime (you can
kind of doit with the Custom edition but it's not all there yet).
Oh, you missed reflection in the above - needs native support for both Java
reflection
and serialization.
> Internal Class Handler - implements Internal class handler interface (ICHI)
> -------------------------------------------------------------------------
> - All bytecode execution models (interpreter, JIT, GCJ...) express
> this interface. The JVM and the internal class handler are
> tightly linked, though separate.
Again, the custom edition has something like this - but it's a work in progress
at the momentand not as flexible as I want it to be nor as you suggest.
> - The JVM would access the information it needs from a class, and
> actually execute methods, through this interface. In turn, the
> executing methods expect to make calls back into the JVM interface,
> but only for (a) native method calls and (b) other JVMII API routines
> which allow for certain optimizations, etc.
> - Exports routines for computing stack traces, examining method local
> variables (for debugging), profiling (?), etc.
> - The JVM allows its invoker to specify the ICHI implementation at startup.
> - How bytecodes are interpreted or executed is opaque.
>
> Kaffe bytecode interpreter
> --------------------------
> - The existing kaffe interpreter code, implementing the ILCI, as a library
>
> Kaffe JIT engine
> ----------------
> - The existing kaffe JIT code, implementing the ILCI, as a library
> - Could look for cached/pre-compiled classes in the filesystem
>
> GCJ "library"
> -------------
> - Same as Kaffe JIT engine, but uses GCJ to do optimized compilation
> of classes.
> - Could look for cached/pre-compiled classes in the filesystem
One of the major problems here is mixing execution engines. The JIT and GCJ are
easybecause both use standard C calling convention. However, mising the
interpreter with
these is hard - especially to do it efficiently. The obvious thing to do is to
make the
interpreter use C calling convention too, but that'll take quite a rewrite of how
it is now
(which might not be a bad idea anyhow).
> Kaffe executable
> ----------------
> - Similar to the existing "Kaffe" program, just links with the JVM
> shared library and runs the class's main().
> - Command line flags:
> -jit Causes it to link in the Kaffe JIT engine shared library
> and register it as the internal class handler.
> -gcj Causes it to link in the GCJ JIT engine shared library
> and register it as the internal class handler.
> -precomp Simply loads and pre-compiles all classes referenced
> transitively by the main() class. Doesn't actually run
> anything, just fills the cache.
> -cache Specify directory for cached/pre-compiled binary class files
>
> Thoughts?
This would be really nice to do, though I think the --precomp option might be
difficult to do well (I suppose you can just follow all found class and method
references - but it doesn't handle reflection). Since GCJ is now available
I also wonder if it's worth making the JIT code saveable - personally I'd
compiled all my common classes (Klasses.jar, pizza.jar) with GCJ, install them
and JIT the rest.
Cheers
Tim
-- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:57 EDT