The VM is not a monolithic piece of code. Since it was designed with
portability and scalability in mind, it heavily utilizes
separate subsystems for:
Threading - Allowing the choice
between an internal, Java-specific user-level thread system (called the
jthread
system), and a native kernel-level
threading system (e.g. POSIX compliant pthreads) for platforms where this
is
available. The first options is
more portable, and usually faster for non-I/O operations (due to less context
switch
overheads); while the latter is
useful if there is a lot of overlapping, asynchronuous I/O, or if Kaffe
is used on a
multiprocessor.
Memory Management - Kaffe has
its own heap management system with a mark-and-sweep garbage collector
(GC). However, there is no ``ideal''
garbage management mechanism (it depends on your application), so Kaffe
provides the ability to replace
the GC with one more appropriate to the application - perhaps a local reference
counting
scheme, a generational collector
or a copying collector for faster allocation.
Native Method Interfacing - There
are two options for the implementation of native methods: the standard
Java
Native Interface (JNI), and the
Kaffe-specific Native Interface (KNI). JNI enables you to write native
libraries which
are portable (within reason) between
different VMs (for the same HW/OS platform). KNI is faster if it comes
to
frequently accessing Java fields
from your native code, but is not as portable.
Native System Calls For portability
reasons (and to ease the implementation of a thread-safe I/O), the target
specific system calls are indirected
via an operating system interface.
The most interesting part of the VM is the execution engine itself,
which comes in two different flavors: interpreter and
``just-in-time'' (JIT). The interpreter is smaller and easier to port
but is significantly slower to execute code. The JIT requires
a layer of macros to be written, containing the actual assembler instructions.
This allows bytecodes to be translated to native
code ``on-demand'' enabling code to be executed at speeds close to
compiled C.
Java Libraries
Beginning with version 1.0, Kaffe now has its own class library, and
no longer requires any third party components. This layer
can be subdivided into:
Core classes (java.lang/io/net/util/text/beans,
etc.)
Graphics classes (java.awt/applet,
etc.)
There are two versions of the graphics classes; one can be used on native
platforms with windowing support (Windows, X,
etc.), the other does not require a native windowing system and can
be used to implement the AWT on top of a simple graphic
libraries (e.g. for use in embedded systems). Both versions utilize
a common set of widgets, which are purely implemented in
Java (as ``lightweights'' and requiring no native widget libraries
such as Motif, etc.). All drawing operations are done from in
Java which mean by simply changing the Java widgets, you can change
the look-and-feel.
Native Libraries
As a consequence of providing our own Java class libraries, Kaffe also
comes with its own, platform specific native libraries. To
enable shrink-wrapped systems, and to ease porting to new platforms,
these libraries can be either dynamic (the usual
configuration) or static.
p.s. the above description is from http://www.transvirtual.com/structure.html
.