harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graeme Johnson <Graeme_John...@ca.ibm.com>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Wed, 13 Jul 2005 17:38:27 GMT
Akhilesh Shirbhate <akhilesh.hacking@gmail.com> wrote on 07/12/2005 
05:18:20 AM:

> Can we have a look at the vmi.h and the list of 18 classes, and
> specially the two classes required for integration ?

As a follow-up to Tim Ellison's response let me provide more detail on 
J9's VM Interface (VMI) and Kernel classes.  Here is the list of 
VM-dependent ?Kernel classes?.  Tim provided some additional details about 
com.ibm.oti.lang.SystemProcess and com.ibm.oti.vm.VM in a follow-up to his 
original post.

    java.lang
       Class
       ClassLoader
       Compiler
       Object
       Package
       Runtime
       StackTraceElement
       String
       Thread
       ThreadGroup
       Throwable
    java.lang.ref
       Reference
       ReferenceQueue
       java.lang.reflect
       AccessibleObject
       Array
       Constructor
       Field
       Method
    java.security
       AccessControlContext
       AccessController
    com.ibm.oti.lang
       SystemProcess
    com.ibm.oti.vm
       VM

As Tim stated, the role of the VMI is to insulate the Java class library 
implementation from internal knowledge of the VM.  Recall that the VMI is 
used by the portion of the class library that is not tightly tied to the 
virtual machine (i.e: non-Kernel classes).  The vast majority of 
non-Kernel classes can be implemented using a combination of Java and 
'pure' JNI code. 

The VMI is a C-based interface, similar to JNI, which provides access to 
VM features that are outside the scope of JNI.  The meat of vmi.h is the 
following structure declaration (somewhat simplified) which defines the 
API between the class library and VM:

    typedef struct VMInterfaceFunctions_* VMInterface;

    struct VMInterfaceFunctions_ 
    {
        vmiError (JNICALL * CheckVersion)(VMInterface* vmi, vmiVersion* 
version);
        JavaVM* (JNICALL * GetJavaVM) (VMInterface* vmi);
        J9PortLibrary* (JNICALL * GetPortLibrary) (VMInterface* vmi);
        JavaVMInitArgs* (JNICALL * GetInitArgs) (VMInterface* vmi);
        vmiError (JNICALL * GetSystemProperty) (VMInterface* vmi, char* 
key, char** valuePtr);
        vmiError (JNICALL * SetSystemProperty) (VMInterface* vmi, char* 
key, char* value);
        vmiError (JNICALL * CountSystemProperties) (VMInterface* vmi, int* 
countPtr);
        vmiError (JNICALL * IterateSystemProperties) (VMInterface* vmi, 
vmiSystemPropertyIterator iterator, void* userData);
    };

Like the JNIEnv the VMInterface is a structure that contains function 
pointers and is associated 1:1 with a JavaVM. 

Structurally, the VMI is built as a shared library (.dll/.so) that exports 
two functions which return a VMInterface given either a JavaVM or a 
JNIEnv.  The class library JNI code is dynamically linked to this shared 
library, and is VM-neutral.  The VMI shared library can be replaced to 
support different VM implementations without modifying the JNI natives 
themselves.

The following sample illustrates how a JNI native could obtain a 
VMInterface and make a simple VMI query.  Note the intentional similarity 
between the JNI and VMI usage.

    jstring JNICALL Java_example_Example_getJavaHome(JNIEnv *env, jclass 
clazz)
    {
        /* Obtain the VM Interface from the JNIEnv */
        VMInterface * vmi = VMI_GetVMIFromJNIEnv(env);
        char* javaHome;

        /* Query the value of java.home using VMI */
        if ((*vmi)->GetSystemProperty(vmi, "java.home",&javaHome) != 
VMI_ERROR_NONE) 
            return NULL;

        return (*env)->NewStringUTF(env,javaHome);
    }

The GetPortLibrary() member of the VMInterface is particularly 
interesting.  This function returns a handle to a J9PortLibrary structure, 
which provides a platform-independent abstraction of operating system 
functionality.  The portability layer includes those features required by 
both the virtual machine and core class library, including:

        Basic I/O (files, sockets, tty)
        Synchronization and threading
        Memory allocation
        Signal handling
        Shared library support
        Operating system and environmental queries

During the development of J9 we found that centralizing VM and core class 
library interfaces to the operating system (and keeping these interfaces 
thin) reduces the porting effort.  If there is sufficient interest I can 
follow up with a more detailed description of the J9 portability library. 

The mailing list is probably not the right forum for posting non-trivial 
pieces of code. Geir: What's the right forum for this sort of discussion?

Graeme Johnson
J9 VM Team, IBM Canada.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message