From: Archie Cobbs (archie@whistle.com)
Date: Fri Sep 11 1998 - 23:14:18 EDT
Godmar Back writes:
> Sun has done this, a Java VM in Java:
>
> http://www.smli.com/technical-reports/1998/abstract-64.html
Definitely an interesting paper.
The most poignant (?) point I got out of it was that the definition
of the Java virtual machine, which I thought was very precisely
defined, is actually rather incomplete.
This is because several classes absolutely require certain native
methods, and these methods can only be implemented by the JVM itself
(eg, java/lang/Object.wait()), yet nowhere is it defined exactly
what these methods are. In effect, the "system" classes become part
of the JVM, but in a fuzzy way.
This is why Klasses.jar is incompatible with classes.zip, because
Sun never published the API between the "system" classes and the JVM.
So two JVM's are never likely to be interchangable because of all the
implementation choice wrt. these native methods.
I know everybody already knows this already :-) but it was interesting
to me to think about it explicitly this way.
More to the point, it might make sense to think about "finishing
the job" with respect to this. In other words, defining the rest of
the API to the JVM. This would include:
- Exactly which native methods are implemented by the JVM itself,
and their semantics.
- A relatively clean API between the JVM and things like the GCJ
code.
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.
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
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.
- 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
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?
-Archie
___________________________________________________________________________
Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 19:56:57 EDT