From harmony-dev-return-1698-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org Wed Jul 13 17:38:41 2005 Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 71941 invoked from network); 13 Jul 2005 17:38:40 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 Jul 2005 17:38:40 -0000 Received: (qmail 34689 invoked by uid 500); 13 Jul 2005 17:38:34 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 34610 invoked by uid 500); 13 Jul 2005 17:38:34 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 34597 invoked by uid 99); 13 Jul 2005 17:38:34 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jul 2005 10:38:34 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_40_50,HTML_MESSAGE,SPF_HELO_FAIL X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [32.97.182.146] (HELO e6.ny.us.ibm.com) (32.97.182.146) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 13 Jul 2005 10:38:31 -0700 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e6.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j6DHcSkh022318 for ; Wed, 13 Jul 2005 13:38:28 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j6DHcSg6213156 for ; Wed, 13 Jul 2005 13:38:28 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j6DHcSGT019329 for ; Wed, 13 Jul 2005 13:38:28 -0400 Received: from d25ml01.torolab.ibm.com (d25ml01.torolab.ibm.com [9.26.6.102]) by d01av02.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j6DHcSt8019304 for ; Wed, 13 Jul 2005 13:38:28 -0400 In-Reply-To: <9089c1dd05071202186d9acb3b@mail.gmail.com> To: harmony-dev@incubator.apache.org MIME-Version: 1.0 Subject: Re: [arch] VM/Classlibrary Interface (take 2) X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Graeme Johnson Message-ID: Date: Wed, 13 Jul 2005 13:38:27 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.5.4|March 27, 2005) at 07/13/2005 13:38:28, Serialize complete at 07/13/2005 13:38:28 Content-Type: multipart/alternative; boundary="=_alternative 0060E5968525703D_=" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N --=_alternative 0060E5968525703D_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Akhilesh Shirbhate wrote on 07/12/2005=20 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=20 J9's VM Interface (VMI) and Kernel classes. Here is the list of=20 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=20 implementation from internal knowledge of the VM. Recall that the VMI is=20 used by the portion of the class library that is not tightly tied to the=20 virtual machine (i.e: non-Kernel classes). The vast majority of=20 non-Kernel classes can be implemented using a combination of Java and=20 'pure' JNI code.=20 The VMI is a C-based interface, similar to JNI, which provides access to=20 VM features that are outside the scope of JNI. The meat of vmi.h is the=20 following structure declaration (somewhat simplified) which defines the=20 API between the class library and VM: typedef struct VMInterfaceFunctions=5F* VMInterface; struct VMInterfaceFunctions=5F=20 { vmiError (JNICALL * CheckVersion)(VMInterface* vmi, vmiVersion*=20 version); JavaVM* (JNICALL * GetJavaVM) (VMInterface* vmi); J9PortLibrary* (JNICALL * GetPortLibrary) (VMInterface* vmi); JavaVMInitArgs* (JNICALL * GetInitArgs) (VMInterface* vmi); vmiError (JNICALL * GetSystemProperty) (VMInterface* vmi, char*=20 key, char** valuePtr); vmiError (JNICALL * SetSystemProperty) (VMInterface* vmi, char*=20 key, char* value); vmiError (JNICALL * CountSystemProperties) (VMInterface* vmi, int* = countPtr); vmiError (JNICALL * IterateSystemProperties) (VMInterface* vmi,=20 vmiSystemPropertyIterator iterator, void* userData); }; Like the JNIEnv the VMInterface is a structure that contains function=20 pointers and is associated 1:1 with a JavaVM.=20 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=20 JNIEnv. The class library JNI code is dynamically linked to this shared=20 library, and is VM-neutral. The VMI shared library can be replaced to=20 support different VM implementations without modifying the JNI natives=20 themselves. The following sample illustrates how a JNI native could obtain a=20 VMInterface and make a simple VMI query. Note the intentional similarity=20 between the JNI and VMI usage. jstring JNICALL Java=5Fexample=5FExample=5FgetJavaHome(JNIEnv *env, jcl= ass=20 clazz) { /* Obtain the VM Interface from the JNIEnv */ VMInterface * vmi =3D VMI=5FGetVMIFromJNIEnv(env); char* javaHome; /* Query the value of java.home using VMI */ if ((*vmi)->GetSystemProperty(vmi, "java.home",&javaHome) !=3D=20 VMI=5FERROR=5FNONE)=20 return NULL; return (*env)->NewStringUTF(env,javaHome); } The GetPortLibrary() member of the VMInterface is particularly=20 interesting. This function returns a handle to a J9PortLibrary structure, = which provides a platform-independent abstraction of operating system=20 functionality. The portability layer includes those features required by=20 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=20 library interfaces to the operating system (and keeping these interfaces=20 thin) reduces the porting effort. If there is sufficient interest I can=20 follow up with a more detailed description of the J9 portability library.=20 The mailing list is probably not the right forum for posting non-trivial=20 pieces of code. Geir: What's the right forum for this sort of discussion? Graeme Johnson J9 VM Team, IBM Canada. --=_alternative 0060E5968525703D_=--