vmintegration.texinfo

linux下建立JAVA虚拟机的源码KAFFE

This method is private, and is used by the other two.
@item @code{newInputStream(ReadableByteChannel)} -- Wraps the channel
in a @code{FileInputStream}.
@item @code{newOutputStream(WritableByteChannel)} -- Wraps the channel
in a @code{FileOutputStream}.
@end itemize

@node gnu.java.nio, java.lang.reflect, java.nio.channels, Classpath Hooks
@section gnu.java.nio

The @code{gnu.java.nio} class provides Classpath implementations of the
interfaces provided by @code{java.nio}.  The VM classes provide the native
support necessary to implement @emph{pipes} and @emph{selectors}.

@menu
* gnu.java.nio.VMPipe::
* gnu.java.nio.VMSelector::
@end menu

@node gnu.java.nio.VMPipe,gnu.java.nio.VMSelector,gnu.java.nio,gnu.java.nio
@subsection @code{gnu.java.nio.VMPipe}

@code{VMPipe} provides the native functionality for a uni-directional pipe
between a source and a destination (sink) channel.  It consists of one 
@code{static} @code{native} method, @code{init(PipeImpl,SelectorProvider)},
the reference implementation of which is currently a native stub.  Ideally,
this should initialise the pipe at the native level.

@node gnu.java.nio.VMSelector,,gnu.java.nio.VMPipe,gnu.java.nio
@subsection @code{gnu.java.nio.VMSelector}

A @code{Selector} selects between multiple @code{SelectableChannel}s based
on their readiness and a key set.  The VM hook for the Classpath implementation
of this is @code{VMSelector}, and this allows the actual @code{select()}
operation to be performed.  This is represented by the @code{static}
@code{native} method, @code{select(int[],int[],int[],long)}, and a default
implementation of this is provided.

@node java.lang.reflect, Classpath Callbacks, gnu.java.nio, Classpath Hooks
@section @code{java.lang.reflect}
@code{java.lang.reflect} provides the interface to Java's reflection
facilities.  Via reflection, programmers can obtain type information about
a particular instance at runtime or dynamically create new instances.

@menu
* java.lang.reflect.VMArray::
@end menu

@node java.lang.reflect.VMArray,,,java.lang.reflect
@subsection @code{java.lang.reflect.VMArray}

The @code{VMArray} class provides a hook, @code{createObjectArray},
which the VM uses to generate a new non-primitive array of a
particular class and size.  The default implementation simply passes
the job down to the standard JNI function, @code{NewObjectArray}.

@node Classpath Callbacks, , java.lang.reflect, Classpath Hooks
Some of the classes you implement for the VM will need to call back to
package-private methods in Classpath:

@itemize @bullet
@item @code{java.lang.ThreadGroup.addThread(Thread)}
Call this method from @code{Thread} when a new @code{Thread} is created, to add it to
the group.

@item @code{java.lang.ThreadGroup.removeThread(Thread)}
Call this method from @code{Thread} when a @code{Thread} is stopped or destroyed.
@end itemize

@node VM Hooks, JNI Implementation, Classpath Hooks, Top
@comment node-name, next, previous, up
@chapter VM Hooks

VMs need to do some dirty work; there are some things in the VM that
unfortunately are dependent on the internal structure of various
classes.  This is a guide to all of the things the VM itself needs to
know about classes.

Some of the core classes, while being implemented by GNU Classpath,
provide space for state (in the form of a @code{vmdata} object) to be
stored by the VM, and can not be constructed normally.

@itemize @bullet
@item java.lang.Class
@item java.lang.ClassLoader
@end itemize

The default implementations of some VM classes also follow this methodology,
when it is intended that most VMs will keep the default.

@itemize @bullet
@item java.lang.VMThread
@item java.lang.VMThrowable
@end itemize

Several core classes must be completely implemented by the VM for Classpath to
work, although reference implementations are provided.  These classes are:

@itemize @bullet
@item java.lang.reflect.Constructor
@item java.lang.reflect.Method
@item java.lang.reflect.Field
@end itemize

The following issues are of note;

@itemize @bullet
@item @code{java.lang.Class} @*
The GNU Classpath implementation of @code{java.lang.Class} provides an
object for storing the internal state of the class maintained by the VM.
This is the only known place where this matters.  The class is
constructed with this data by the VM.  Some VMs do not create the
@code{Class} object at the point where the class is defined; instead,
they wait until a @code{Class} object is actually used.

@item Array Classes @*
When you are creating an array class, you should set the
@code{ClassLoader} of the array class to the @code{ClassLoader} of its
component type.  Whenever you add a class to a @code{ClassLoader}, you
need to notify the @code{ClassLoader} and add the new @code{Class} to
its internal cache of classes.  To do this, call
@code{ClassLoader.addVMCreatedClass(Class)}.  @emph{Note: this is
written in anticipation of 1.2 support and does not apply just yet.}

@item Primordial Class Loader @*
When the primordial class loader loads a class, it needs to tell
Classpath what it has done in order for security stuff to work right.
To do this, call the static method
@code{ClassLoader.newPrimordialClass(Class)}.

Even the first few core classes need to do this; in order to do it,
simply call this method @emph{after} the initial class loading has been
done.  No harm will come, as long as you follow the guidelines in the
@pxref{Initialization} section.

@emph{Note: this is written in anticipation of 1.2 support and does not
apply just yet.}

@item Top-level Exception Handler @*
Exceptions take care of themselves in Classpath; all you need to do in
the top-level exception handler is call @code{Throwable.printStackTrace()}.

@item Security and Traces @*
There will eventually be a feature in the 1.2 security that keeps the
@code{AccessController} from having to evaluate @emph{all} of the
@code{ProtectionDomain}s every time a security check is made.  I think a common
case is a single method doing a lot of things that require security
checks.  However, I don't want to bog down the method stack too much, so
this feature of the VM will have the @code{AccessController} for a thread
calling out to the VM to tell it how high it was on the stack when it
made the last security request.  Every time the stack goes lower than
that number, the VM will decrement the number.  The @code{AccessController}
will remember what the accumulated protection status was at every stack
level (an @code{AccessControlContext}) and use that aggregated information to
do the check.  I am not sure, however, whether the savings are
substantial enough to outweigh the integer check and set after every
method call.  I will investigate.

@item Threading @*
I figured I'd put this here because a VM guy might be wondering about it.
We implement @code{ThreadGroup}, but that class is almost entirely
VM-independent.  The root @code{ThreadGroup}, a static field called
@code{ThreadGroup.root}, should be initialized by Classpath, but if you wish to
reinitialize it yourself, there should be no harm.

@end itemize

@node JNI Implementation, Miscellaneous VM Requirements, VM Hooks, Top
@comment  node-name,  next,  previous,  up
@chapter JNI Implementation

Classpath comes with its own implementation of @file{jni.h}.  This
file can be customized by the VM in a few ways, by defining macros
that affect the interpretation of the file.  These macros are all
intended for use by a VM which uses GNU Classpath and which wants to
use a single copy of @file{jni.h} for both internal and external use.

@itemize @bullet
@item _CLASSPATH_VM_JNI_TYPES_DEFINED
Some VMs like to define JNI ``object'' types in a special way.  If
this macro is defined, the Classpath @file{jni.h} will avoid defining
these types.  By default, these types are defined in @file{jni.h}.
The full list of types and macros treated this way is: @samp{jobject},
@samp{jclass}, @samp{jstring}, @samp{jthrowable}, @samp{jweak},
@samp{jarray}, @samp{jobjectArray}, @samp{jbyteArray},
@samp{jshortArray}, @samp{jintArray}, @samp{jlongArray},
@samp{jbooleanArray}, @samp{jcharArray}, @samp{jfloatArray},
@samp{jdoubleArray}, @samp{JNIEnv}, @samp{JavaVM}, @samp{JNI_TRUE}
(macro), @samp{JNI_FALSE} (macro).

@item _CLASSPATH_VM_INTERNAL_TYPES_DEFINED
If the VM has its own definitions for @samp{jfieldID} and
@samp{jmethodID}, then it should define this macro.  Otherwise,
@file{jni.h} will provide definitions for these types.

@item _CLASSPATH_JNIIMPEXP
Three functions -- @samp{JNI_GetDefaultJavaVMInitArgs},
@samp{JNI_CreateJavaVM}, and @samp{JNI_GetCreatedJavaVMs} -- must be
marked as @samp{JNIIMPORT} when seen by user code, but most likely
should be marked as @samp{JNIEXPORT} when defined in the VM
implementation.  This macro can be defined to one or the other by the
VM as appropriate.  If this macro is not defined, it defaults to
@samp{JNIIMPORT}.

@item _CLASSPATH_JNIENV_CONTENTS
A VM can add fields to the @samp{JNIEnv} structure by defining this to
be a sequence of field declarations.

@end itemize


@node Miscellaneous VM Requirements,  , JNI Implementation, Top
@comment  node-name,  next,  previous,  up
@chapter Miscellaneous VM Requirements

Classpath places a few requirements on the VM that uses it.

@menu
* JNI Version::                 
* VM Threading Model::          
* Boot Library Path Property::
@end menu

@node JNI Version, VM Threading Model, Miscellaneous VM Requirements, Miscellaneous VM Requirements
@comment  node-name,  next,  previous,  up
@section JNI Version

Classpath currently uses only JNI 1.1, except for one JNI 1.2 function
in the JNI Invocation API: GetEnv().  And GetEnv() is only used in the
``portable native sync'' code, so it's only actually used by Jikes RVM
and Kaffe.  

A future direction will probably be to require that all VMs provide
JNI 1.2.  If this poses problems, please raise them on the classpath
mailing list. 

@node VM Threading Model, Boot Library Path Property, JNI Version, Miscellaneous VM Requirements
@comment  node-name,  next,  previous,  up
@section VM Threading Model

Classpath's AWT peers use GTK+.  GTK+ uses GLIB.  Normally, Classpath
will initialize GLIB's @dfn{gthreads} to use
the platform's native threading model@footnote{The native threading
model is pthreads on Linux and AIX, the two platforms Classpath
currently runs on.}

If the Java runtime doesn't use the native threading model, then you
will want Classpath to tell GLIB to use the Java threading primitives
instead.  Otherwise, GLIB would use the native threading model to
perform operations such as creating thread-local data, and that just
doesn't work on systems (such as Kaffe in some configurations, and
such as Jikes RVM) that use @i{m}:@i{n} threading.

Historically, enabling the Java threading primitives had been done at
build time, by configuring classpath with the
@option{--portable-native-sync} option.  This had bad consequences,
though -- it meant that the prebuild GNU Classpath package distributed
with Debian GNU/Linux would not be usable with VMs that could
otherwise have used it.  Instead, we encourage
the use of the Java system property
@code{gnu.classpath.awt.gtk.portable.native.sync}.  A VM that wants
GLIB to use the Java threading primitives should modify
@code{VMRuntime.insertSystemProperties()} to include code like the
following:

@example
static void insertSystemProperties(Properties @var{p}) 
@end example
...
@example
@var{p}.put("gnu.classpath.awt.gtk.portable.native.sync", "true");
@end example

So, the configure option
@option{--portable-native-sync} is deprecated, and should go away in a
subsequent release of GNU Classpath.

@node Boot Library Path Property,  , VM Threading Model, Miscellaneous VM Requirements
@comment  node-name,  next,  previous,  up
@section Boot Library Path Property

As of GNU Classpath 0.15 a system property named @code{gnu.classpath.boot.librar