This page aims to document places within OpenJDK where HotSpot makes calls into the class library, including cases where specialist constructors/methods are provided for this purpose.
The VM is expected to load libjava.so in order that the native methods required by
the core classes (java.lang.Object, etc.) can be accessed and so that the JVM_ symbols
in this library are resolved against the VM's implementation. More specific libraries (e.g. awt, net)
instead use an explicit call to LoadLibrary.
A java.lang.Thread instance needs to be created for the new 'main' thread. This in
turn needs a java.lang.ThreadGroup. In OpenJDK, the 'main' thread is in the 'main'
thread group, both of which can be created by calls to the same public constructors for these classes
used from Java. The catch is that any new ThreadGroup needs a parent; the solution is
to use a private no-argument constructor of ThreadGroup which creates the root 'system'
group which can then be used as main's parent. All this takes place in create_initial_thread_group
and create_initial_thread in src/share/vm/runtime/thread.cpp.
The JNI interface was extended in 1.4 to allow a ByteBuffer instance to be created from a native buffer.
Three new methods, jni_NewDirectByteBuffer, jni_GetDirectBufferAddress and
jni_GetDirectBufferCapacity allow a buffer to be created and its attributes retrieved respectively.
Creating the buffer involves calling the constructor of java.nio.DirectByteBuffer with the address
(in the form of a Java long i.e. 64 bits) and the buffer's capacity. These same values need to be retrieved
by the other two methods using direct field access rather than methods. Notably, GNU Classpath uses an object
to encapsulate the pointer rather than a long; a similar solution for OpenJDK may be worth considering. The
implementation (complete with caching by initializeDirectBufferSupport) can be found in src/share/vm/prims/jni.cpp