[Top] [Contents] [Index] [ ? ]

GNU Classpath Hacker's Guide

This file contains important information you will need to know if you are going to write an interface between GNU Classpath and a Virtual Machine.

Copyright (C) 1998-2002, 2004, 2005, 2006 Free Software Foundation, Inc.

This file contains important information you will need to know if you are going to write an interface between GNU Classpath and a Virtual Machine.

This document is incomplete, as we are still in alpha with the interface.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

1. Introduction

The Classpath Project's ambition to be a 100% clean room implementation of the standard Java class libraries cannot be fulfilled without some level of integration with the Virtual Machine, the underlying machinery that actually runs Java.

There are several VMs out there, here is a small list.

In the past integration efforts were focused mainly on Japhar with an eye towards getting Electrical Fire to work. Most information contained in this document is gleaned from these efforts. Recently more work has been done on getting gcj, orp and kissme to work out of the box with GNU Classpath but there is much to do before that becomes a reality.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

2. Initialization

The order of initialization, as far as I can tell, doesn't matter just yet. However, when we move to 1.2 support, it probably will matter, so we'll have a note in here at that time.

The initialization order is currently documented in the `Runtime.java' source file.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3. Classpath Hooks

The primary method of interaction between Classpath and the VM is via the helper classes, which are named after the relevant core library class, but include an additional `VM' prefix. The library classes from Classpath call out to these to get certain VM-specific dirty work done. A reference copy of each VM class exists. The majority consist of a series of static methods, some of which are simply declared native, and some which provide a default implementation. VMs may either use these as is, or create their own local variations. When using the default implementations, the VM is responsible for implementing any of the code marked as native which corresponds to functionality they wish their VM to provide. When using their own versions of the classes, VM implementors may choose to change the mix of native and non-native methods from that below, so as to best suit their implementation.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1 java.lang

java.lang is the core Java package, being imported automatically by all classes. It includes basic classes as Object and String. A VM must implement at least some parts of this package in order to become operable.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.1 java.lang.VMClass

The core class, java.lang.Class, and the corresponding VM class, java.lang.VMClass, provide two main functions within GNU Classpath.

  1. For basic VM operation, java.lang.Class provides the link between the Java-based representation of a class it embodies and the VM's own internal structure for a class. See section VM Hooks.
  2. As far as the user is concerned, the main function of java.lang.Class is as an entry point to the reflection facilities, and so it also provides this functionality, backed by the VM class.

This VM class lists the following methods, organized by the version of the Java specification in which they occur. All are native, unless otherwise specified, and pertain to reflection. As a result, the VM only needs to implement these methods in order to provide reflection support, and then only to the degree required.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.2 java.lang.VMObject

VMObject is the bridge between the low level Object facilities such as making a clone, getting the class of the object and the wait/notify semantics. This is accomplished using the following native methods.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.3 java.lang.VMClassLoader

VMClassLoader provides methods for defining and resolving core and primitive classes, as well as handling resources, packages and assertions. The class is a mixture of native methods and Java-based implementations, with some of the latter being stubs.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.4 java.lang.VMSystem

VMSystem handles the default I/O streams, provides access to the system clock and environment variables and provides methods for System.arraycopy and the identityHashCode of an Object. It consists of native methods, but the default implementation also provides some helper methods to simplify stream creation.

Classpath also provides native implementations of

making a VM implementation optional.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.5 java.lang.VMThrowable

VMThrowable is used to hold the VM state of a throwable, created either when a Throwable is created or the fillInStackTrace() method is called (i.e. when the actual stack trace is needed, as a lot of exceptions are never actually used). The actual class has two native methods, one (fillInStackTrace()) being a method of the class used to obtain instances, and the other an instance method, getStackTrace().


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.6 java.lang.VMCompiler

VMCompiler provides an interface for VMs which wish to provide JIT compilation support. The default implementation is simply a series of stubs. The property, java.compiler, should point to a library containing the function java_lang_Compiler_start() if such support is to be provided.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.7 java.lang.VMDouble

VMDouble provides native support for the conversion and parsing of doubles.

Classpath provides native implementations of all these, making VM implementation optional.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.8 java.lang.VMFloat

VMFloat provides native support for the conversion of floats.

Classpath provides native implementations of all these, making VM implementation optional.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.9 java.lang.VMProcess

VMProcess handles the execution of external processes. In the default implementation, threads are spawned and reaped by ProcessThread. A constructor creates a new VMProcess, which extends rather than complements Process, using an array of arguments, an array of environment variables and a working directory. The instance maintains system input, output and error streams linked to the external process. Three native methods are used, and implementations are provided for all three by Classpath, making VM implementation optional. These use the POSIX functions, fork(), waitpid() and kill().


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.10 java.lang.VMRuntime

The VMRuntime class provides a series of native methods which divulge information about the runtime or invoke certain operations. This includes retrieving the amount of available memory, and scheduling the garbage collector. There are two exceptions: the enableShutdownHooks method, which allows the VM to put in its own shutdown hooks when Runtime.addShutdownHook() is first invoked, and exec(String[],String[],File) which spawns an external process. These are Java-based static methods instead. The first is simply a stub by default, while the second simply links to the functionality of VMProcess (and should be changed if a different Process implementation is used).


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.11 java.lang.VMString

VMString is responsible for handling interned strings. If two strings are equal (using the equals() method), then the results of calling the intern() method on each of them makes them equal (using ==). Thus, the same string object is always returned by intern if the two strings are equal. The default implementation is Java-based and implements intern(String) by maintaining a WeakHashMap which links the strings to their WeakReference. A new mapping is created for each new string being interned. A VM may implement this differently by implementing this method, which is static and the only one in VMString.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.12 java.lang.VMThread

VMThread provides the link between Java's threads and the platform threading support. A VMThread is created via a private constructor and linked to a Thread instance. This occurs when the Thread instance is started by the static create(Thread,long) method (the second argument requests a certain stack size, usually zero). The thread itself is executed via the run() method, which handles any problems with the running of the thread and its eventual death.

VMThread provides the following accessors and mutators for accessing the thread state via VMThread,

all of which refer to the Thread instance. setPriority(int) also calls the appropriate native method. stop(Throwable) similarly wraps a native method, merely adding in a check for the state of the thread.

The default implementation also provides Java-based implementations of join(long,int), sleep(long,int) and holdsLock(Object). join and sleep simply wait for the appropriate amount of time, with join additionally waiting for the thread instance to become null. holdsLock simply checks if an object is locked by the current thread by trying to invoke the notify method, and catching the failing exception if this is not the case.

The remainder of the class is a series of native methods, some of which are mandatory for VM implementation and others which provide optional or deprecated functionality.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.1.13 java.lang.VMMath

The VMMath class provides a series of native methods for some of the mathematical functions present in java.lang.Math. Classpath provides a default implementation of these which maps the functions to those provided by fdlibm. VM implementors are welcome to replace this with more efficent implementations, as long as the accuracy contract of these methods, specified in java.lang.Math, is maintained.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2 gnu.classpath

The gnu.classpath package provides Classpath-specific functionality, primarily relating to the features in java.lang. At present, this includes the context of a class (the stack) and the system properties.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2.1 gnu.classpath.VMStackWalker

VMStackWalker provides access to the class context or stack. The default implementation consists of a native static method, getClassContext(), which obtains the class context, and two helper methods which obtain the calling class (the 3rd element in the context array) and its class loader, respectively.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2.2 gnu.classpath.VMSystemProperties

VMSystemProperties allows the VM to hook into the property creation process, both before and after the system properties are added by GNU Classpath. The default implementation assumes that the VM will add its properties first, by making the pre-initialisation method native, and that the Classpath properties may then be altered by a Java-based post-initialisation method.

As these methods are called as part of the bootstrap process, caution should be used as to what classes are used, and properties should only be set using Properties.setProperty(). Specifically, I/O classes should be avoided at this early stage.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.2.3 gnu.classpath.Unsafe

The Unsafe class provides access to some low-level unsafe operations as required by the addition of the java.util.concurrent classes. These focus on direct memory access to the fields within the VM and providing atomic update methods.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.3 java.util

The java.util VM hooks provide links between the mix of functionality present in that package, which includes collections, date and time handling and parsing. At present, there is only one hook, which connects GNU Classpath to the timezone information provided by the underlying platform.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.3.1 java.util.VMTimeZone

VMTimeZone joins TimeZone to the platform timezone information via the static method, getDefaultTimeZoneId(). The VM hook is expected to return a TimeZone instance that represents the current timezone in use by the platform. The default implementation provides this functionality for POSIX or GNU-like systems, and VMs that want this functionality can keep this implementation and implement the native method, getSystemTimeZoneId(). This method is only called when obtaining the timezone name from the TZ environment variable, /etc/timezone and /etc/localtime all fail. This fallback mechanism also means that a system which doesn't provide the above three methods, but does provide a timezone in string form, can still use this implementation.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4 java.io

The java.io package is heavily reliant on access to the I/O facilities of the underlying platform. As far as its VM hooks go, they provide two areas of functionality to GNU Classpath, these being

The first corresponds directly to most of the File class, while the latter underlies the functionality provided by the ObjectInputStream and ObjectOutputStream. More low-level I/O is provided by java.nio.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4.1 java.io.VMFile

VMFile allows GNU Classpath's File representations to probe and modify the file system using the native functions of the platform. The default implementation (which consists of both a VMFile class and the native methods) is primarily UNIX-centric, working with POSIX functions and assuming case-sensitive filenames, without the restriction of the 8.3 format. It consists mainly of static native methods, with a few Java helper methods. The native methods represent the file as a string containing its path, rather than using the object itself.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4.2 java.io.VMObjectInputStream

This class consists of two methods which provide functionality used in deserializing an object. currentClassLoader() provides the first user-defined class loader from the class context (See section gnu.classpath.VMStackWalker,) via a PrivilegedAction. allocateObject(Class,Class,Constructor) is a native method (a reference implementation is provided) which creates an object but calls the constructor of another class, which is a superclass of the object's class.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.4.3 java.io.VMObjectStreamClass

VMObjectStreamClass is a series of static native methods that provide some of the groundwork for ObjectStreamClass and ObjectStreamField. hasClassInitializer(Class) works with the former, and checks for the presence of a static initializer. The remaining methods are of the form setXXXNative(Field,Object,XXX) and support ObjectStreamField. One exists for each of the main types (boolean, float, double, long, int, short, char, byte and object) and is used to set the specified field in the supplied instance to the given value.

A default implementation is provided for all of them, so a VM implementation is optional.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.5 java.security

The java.security package provides support for Java's security architecture.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.5.1 java.security.VMAccessController

The AccessController is used to perform privileged actions. Its hook class, VMAccessController, maintains the AccessControlContext and the default implementation is purely Java-based. The VM may choose to replace this with their own. The methods in the reference version are as follows:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.5.2 java.security.VMSecureRandom

The VMSecureRandom class is used to provide access to cryptographically secure random numbers. The default implementation of the class runs eight threads that increment counters in a tight loop, and XORs each counter to produce one byte of seed data. This is not very efficient, and is not guaranteed to be random (the thread scheduler is probably deterministic, after all). VM implementors should provide a version of this class, which implements the method generateSeed(byte[],int,int), so that it fills the buffer using a random seed from a system facility, such as a system entropy gathering device or hardware random number generator. The parameters are the usual set of buffer, offset and length and the method returns the number of bytes actually generated, which may be less than that requested.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.6 java.net

The java.net package is heavily reliant on access to the networking facilities of the underlying platform. The VM hooks provide information about the available network interfaces, and access to lookup facilities for network addresses.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.6.1 java.net.VMInetAddress

VMInetAddress is a series of static native methods which provide access to the platform's lookup facilities. All the methods are implemented by GNU Classpath, making VM implementation optional, and are as follows:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.6.2 java.net.VMNetworkInterface

VMNetworkInterface currently consists of a single static native method, getInterfaces(), which retrieves the network interfaces available on the underlying platform as a Vector. The current GNU Classpath implementation is a native stub.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.7 java.nio

The java.nio package is part of the New I/O framework added in Java 1.4. This splits I/O into the concepts of buffers, charsets, channels and selectors, and java.nio defines the buffer classes. As far as native and VM code is concerned, the new package needs support for low-level efficient buffer operations.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.7.1 java.nio.VMDirectByteBuffer

A ByteBuffer maintains a buffer of bytes, and allows it to be manipulated using primitive operations such as get, put, allocate and free. A direct buffer avoids intermediate copying, and uses native data which shouldn't be manipulated by a garbage collector. The VM class consists of static native methods, all of which are given default implementations by GNU Classpath.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.8 java.nio.channels

Channels provide the data for the buffers with the New I/O packages. For example, a channel may wrap a file or a socket. The VM hooks, at the moment, simply allow the channels to be accessed by java.io streams.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.8.1 java.nio.channels.VMChannels

VMChannels provides the methods that create the channels or streams. The default implementation is in pure Java and simply wraps the channels in standard I/O classes from java.io.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.9 gnu.java.nio

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.9.1 gnu.java.nio.VMPipe

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.9.2 gnu.java.nio.VMSelector

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.10 java.lang.reflect

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.10.1 java.lang.reflect.VMArray

The VMArray class provides a hook, 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, NewObjectArray.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.11 gnu.java.lang

gnu.java.lang provides VM interfaces for the GNU implementations of features in java.lang. Currently, this includes the implementation of instrumentation.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.11.1 gnu.java.lang.VMInstrumentationImpl

The gnu.java.lang.VMInstrumentationImpl and gnu.java.lang.InstrumentationImpl classes provide an implementation of the java.lang.instrument.Instrument interface. A InstrumentationImpl object should be created by the VM when agents are given in the command line (see the java.lang.instrument package documentation). The VM has to set the static field VMClassLoader.instrumenter to this object. The VM should implement the static native methods of the VMInstrumentationImpl class.

Instrumentation allows to modify the bytecode of a class before it gets read by the VM. In GNU Classpath, the ClassLoader.defineClass method calls the VMClassLoader.defineClassWithTransformers method which first checks if VMClassLoader.instrumenter is null. If it's the case, it directly calls VMClassLoader.defineClass. If it's not the case, the method calls at first the InstrumentationImpl.callTransformers method, which calls each transformer registered to the InstrumentationImpl object and returns a new bytecode array. Then, it calls the VMClassLoader.defineClass method with this new bytecode array.

The second use of instrumentation is to redefine a class after it has been loaded by the VM. This is done in the Java application by calling the Instrumentation.redefineClasses method of the standard interface on a Instrumentation object. The InstrumentationImpl.redefineClasses method calls the VMInstrumentationImpl.redefineClasses native method which must be implemented by the VM. The implementation should call the InstrumentationImpl.callTransformers method.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12 gnu.java.lang.management

gnu.java.lang.management provides the VM interfaces for the GNU implementations of the management beans.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.1 gnu.java.lang.management.VMRuntimeMXBeanImpl

The gnu.java.lang.management.RuntimeMXBeanImpl provides an implementation of the java.lang.management.RuntimeMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMRuntimeMXBeanImpl. This provides a series of methods, which should be implemented by the virtual machine in order to provide the required information for the bean. The VM methods are generally representative of information that is only available from the virtual machine, such as the command-line arguments it was given at startup.

The methods are as follows:

The virtual machine also needs to provide either the sun.boot.class.path or java.boot.class.path property in order to support the optional boot class path retrieval functionality.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.2 gnu.java.lang.management.VMClassLoadingMXBeanImpl

The gnu.java.lang.management.ClassLoadingMXBeanImpl provides an implementation of the java.lang.management.ClassLoadingMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMClassLoadingMXBeanImpl. This provides a series of methods, which should be implemented by the virtual machine in order to provide the required information for the bean. Implementing this bean requires the VM to monitor when classes are loaded and unloaded, and provide the option of verbose class loading output.

The methods are as follows:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.3 gnu.java.lang.management.VMThreadMXBeanImpl

The gnu.java.lang.management.ThreadMXBeanImpl provides an implementation of the java.lang.management.ThreadMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMThreadMXBeanImpl. This provides a series of methods, which should be implemented by the virtual machine in order to provide the required information for the bean. Implementing this bean requires the VM to monitor thread-related statistics such as how often the blocked and waiting states have been entered, as well as additional optional support for time and contention monitoring.

Optional support is determined by the following properties:

In addition, the property gnu.java.lang.management.ThreadTimeInitallyEnabled may be set to the String value, "true", if time monitoring is enabled at startup.

The methods are as follows:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.4 gnu.java.lang.management.VMMemoryMXBeanImpl

The gnu.java.lang.management.MemoryMXBeanImpl provides an implementation of the java.lang.management.MemoryMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMMemoryMXBeanImpl. This provides a series of methods, which should be implemented by the virtual machine in order to provide the required information for the bean. Implementing this bean requires the VM to monitor the levels of heap and non-heap memory, and provide the number of objects which are eligible for garbage collection.

The methods are as follows:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.5 gnu.java.lang.management.VMCompilationMXBeanImpl

The gnu.java.lang.management.CompilationMXBeanImpl provides an implementation of the optional java.lang.management.CompilationMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMCompilationMXBeanImpl. This provides a single method for returning the number of milliseconds the virtual machine's Just-In-Time (JIT) compiler has spent compiling. Even if a JIT compiler is available and an instance of the bean supplied, this method is still optional.

Optional support is determined by the following properties:

Time support is implemented by the following method:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.6 gnu.java.lang.management.VMMemoryPoolMXBeanImpl

The gnu.java.lang.management.MemoryPoolMXBeanImpl provides an implementation of the optional java.lang.management.MemoryPoolMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMMemoryPoolMXBeanImpl. Providing this interface requires implementing a number of methods for each supported pool. These return statistics on memory usage, and, optionally, allows monitoring of when memory usage exceedes a preset threshold.

Optional support is determined by the following properties:

The methods are as follows (all take a pool name as their first parameter):


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.7 gnu.java.lang.management.VMMemoryManagerMXBeanImpl

The gnu.java.lang.management.MemoryManagerMXBeanImpl provides an implementation of the optional java.lang.management.MemoryManagerMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMMemoryManagerMXBeanImpl. Providing this interface requires implementing two methods (each takes the name of the manager as the first argument):


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.12.8 gnu.java.lang.management.VMGarbageCollectorMXBeanImpl

The gnu.java.lang.management.GarbageCollectorMXBeanImpl provides an implementation of the optional java.lang.management.GarbageCollectorMXBean interface, and is supported by VM functionality in the form of gnu.java.lang.management.VMGarbageCollectorMXBeanImpl. Providing this interface requires implementing two methods (each takes the name of the garbage collector as the first argument):

Note that each garbage collector is also a memory manager, and so an implementation of the gnu.java.lang.management.VMMemoryManagerMXBeanImpl methods for its name should also be provided.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.13 java.lang.management

gnu.java.lang.management provides the VM interfaces for the GNU implementations of the management beans.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

3.13.1 java.lang.management.VMManagementFactory

This VM interface provides the names of the memory pools, memory managers and garbage collectors for use by the java.lang.management.ManagementFactory in creating lists of appropriate beans for these types of managed object.

The methods are as follows:

Some of the classes you implement for the VM will need to call back to package-private methods in Classpath:


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4. 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 vmdata object) to be stored by the VM, and can not be constructed normally.

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

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

The following issues are of note;


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

5. JNI Implementation

Classpath comes with its own implementation of `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 `jni.h' for both internal and external use.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

6. JVMTI Implementation

Classpath comes with its own implementation of `jvmti.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 for use by a VM which uses GNU Classpath and which wants to use a single copy of `jvmti.h' for both internal and external use.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7. Miscellaneous VM Requirements

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


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7.1 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 now deprecated "portable native sync" code.

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.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7.2 VM Threading Model

VM authors can implement a number of different threading models. When native code is also threaded there is the potential for one threading model to deadlock the other. The Java Native Interface Programmer's Guide and Specification suggests consulting VM documentation in such situations. Classpath uses existing libraries, for example the AWT peers can use the GTK+ graphics library. As these libraries assume a different threading model, there is the potential for the native code to deadlock a VM.

The different threading models available to a VM author are:

  1. Native threads: Map a Java thread to an underlying operating system thread (normally a POSIX compatible pthread). This approach reduces the potential for deadlock as there is only one thread scheduling mechanism.
  2. Green threads 1: Green threads are threads scheduled by the VM, typically by switching swapping registers. In early VMs green threads were seen as advantageous as they didn't require the operating system to resechedule, save and swap all of a threads registers. The green thread 1 model switches thread on an externally created event, such as a timer interrupt. An example of a VM using this approach is Kaffe configured with its jthreads model.
  3. Green threads 2: The essential difference with this model is to not switch threads on an event, but at fixed points in the code being executed by the VM. Points chosen could be backward branches (loops) or method calls. This approach can be advantageous to nonconservative garbage collectors, as non-running threads would be at known points and can have fixed register maps. It can also reduce the number of registers it is necessary to swap when switching threads.
  4. M:N threading: a flaw to green threading is that it is unable to use multiple processors. M:N threading fixes this problem by running groups of green threads on multiple underlying native threads. An example of a VM using this approach is the Jikes RVM, which uses M:N threading combined with the green thread 2 model.

An example of the problem of mixing threading models is:

VMs that don't use the underlying operating system thread scheduling mechanism need to avoid deadlock. One now deprecated approach was to build Classpath and VMs on top of a wrapper thread library (aka portable native sync). The wrapper thread library used was GLIB's gthreads. This approach has been deprecated because:

  1. The wrapper library is only in use by some native libraries. For example, GTK+ uses the gthread library but QT does not.
  2. The wrapper library can't be in use prior to the VM starting as the VM must replace the wrapper libraries functions with its own. This prevents the VM from running as a plugin in an application that already uses the wrapper library.

An alternative approach is for the VM to detect deadlocked native code and swap Java threads off of that native thread. The VM can't, however, swap two blocked native threads that are potentially deadlocking each other on a lock. The lock will be associated with the native thread. To prevent this from happening the VM must hijack functions that operate on locks. This is done by redifining the lock functions inside the VM and configuring the linker so that it uses the VMs symbol in preference to that of the external thread support library. The VM's lock function can then reschedule Java threads if it must wait for the lock.


[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

7.3 Boot Library Path Property

As of GNU Classpath 0.15 a system property named gnu.classpath.boot.library.path can be set by the VM to specify the directories which contain GNU Classpath's native libraries. Usually this value is given at configuration time and is then hardcoded in the VM. However for development purposes it is handy to switch to another installation by overriding the properties' value on the command line.

A VM that does not support this feature can simply ignore the property.

For compatibility reasons we suggest to set the default value of java.library.path to the value of the LD_LIBRARY_PATH environment if it exists on your platform.


[Top] [Contents] [Index] [ ? ]

About This Document

This document was generated by Mark Wielaard on December, 17 2006 using texi2html 1.76.

The buttons in the navigation panels have the following meaning:

Button Name Go to From 1.2.3 go to
[ < ] Back previous section in reading order 1.2.2
[ > ] Forward next section in reading order 1.2.4
[ << ] FastBack beginning of this chapter or previous chapter 1
[ Up ] Up up section 1.2
[ >> ] FastForward next chapter 2
[Top] Top cover (top) of document  
[Contents] Contents table of contents  
[Index] Index index  
[ ? ] About about (help)  

where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure:


This document was generated by Mark Wielaard on December, 17 2006 using texi2html 1.76.