usman bashir wrote: > i am looking the same sort of things from IBM guys, as if i am not wrong > they claim to do same sort of things before :) > and it will really help full if we can have two baselines to work on.
This would work better with a diagram, ... IBM has a set of class libraries (only a subset of SE) that have been independently developed, i.e. based on the spec. These are designed to be portable across VM implementations but have been principally written against J9. Other VMs can run the class library by implementing the JNI + VMI interface. Here "the VM" is defined as the interpreter etc. _plus_ a core set of kernel classes. This structure has already been described here [1]. The class library natives and J9 VM in turn go through the port layer to the OS. I described the port lib briefly here [2]. Apart from 'portability', the port lib structure gives a degree of isolation and control over VM instances by associating resource use with a particular VM instance. Regards, Tim [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200507.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] > On 8/29/05, Geir Magnusson Jr. <[EMAIL PROTECTED]> wrote: > >>And on the wiki after posting here, please? :) >> >>geir >> >>On Aug 19, 2005, at 12:33 PM, Tim Ellison wrote: >> >> >>>Weldon Washburn wrote: >>> >>> >>>>On 7/11/05, Tim Ellison <[EMAIL PROTECTED]> wrote: >>>> >>>> >>>> >>>>>Recently, within IBM, we have been defining the interface between >>>>>IBM's >>>>>class library and the J9 VM. We deliberately haven't looked at >>>>>the GNU >>>>>Classpath/VM interface specification. >>>>> >>>>>The principal goals are to enable the class libraries to be >>>>>hosted on >>>>>different versions of a virtual machine, and potentially different >>>>>virtual machines, without sacrificing performance or introducing >>>>>complexity. In our design, this results in a number of class types >>>>>being (architecturally) labeled as 'kernel classes'. Kernel >>>>>classes can >>>>>be thought of as part of the VM and have to be written by the >>>>>VM-provider. With a thoughtful set of kernel classes the API >>>>>from class >>>>>library to the VM, and from VM to class libraries, can be kept >>>>>remarkably small. Our complete VM/Classlibrary interface >>>>>comprises a >>>>>short C header (vmi.h), about 18 classes defined by 1.4 public API >>>>>(java.lang, java.lang.reflect, ...), and two classes that are >>>>>specifically to support the interface. We are working on necessary >>>>>extensions to this interface for 1.5. >>>>> >>>>>If there is an interest, we can share the interface we are using and >>>>>evolve it as part of harmony. >>>>> >>>> >>>> >>>>Tim, >>>>It would be good if you would go ahead and post the VM/Classlibrary >>>>interface you describe above on harmony wiki. >>>>Thanks >>>>Weldon >>>> >>> >>>I'm just about to leave for a week's vacation, so rather than post and >>>then disappear, I'll wait until I get back and can engage in proper >>>discussion. >>> >>>Regards, >>>Tim >>> >>> >>> >>>>>It would be great if we could share >>>>>experiences with the GNU Classpath VM interface in such a way >>>>>that the >>>>>Harmony interface was suitable for the widest variety of VMs and >>>>>class >>>>>libraries. >>>>> >>>>>Regards, >>>>>Tim >>>>> >>>>>-- >>>>> >>>>>Tim Ellison ([EMAIL PROTECTED]) >>>>>IBM Java technology centre, UK. >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>-- >>> >>>Tim Ellison ([EMAIL PROTECTED]) >>>IBM Java technology centre, UK. >>> >>> >> >>-- >>Geir Magnusson Jr +1-203-665-6437 >>[EMAIL PROTECTED] >> >> >> > > > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
