harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [arch] VM/Classlibrary Interface (take 2)
Date Tue, 12 Jul 2005 11:13:32 GMT

Geir Magnusson Jr. wrote:
> 
> On Jul 11, 2005, at 12:14 PM, Tim Ellison 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.
> 
> 
> what is in the two classes that are needed to support the interface?
>
> IOW, what functionality is needed?

Some parts of the class library implementation require functionality
that is not part of the regular Java API and is (typically) VM-specific.

In our interface, these are pulled out into the VM and SystemProcess
classes, and it becomes the responsibility of the VM-author to provide
an implementation. All the methods on the VM class are static.  The
javadoc for these classes has a full specification, but briefly, the VM
class has:

static ClassLoader getStackClassLoader(int)
   Answers the ClassLoader for the method at the given stack depth.

static ClassLoader getNonBootstrapClassLoader()
   Answers the most recent non-null/non-bootstrap class loader
   on the current stack.

static ClassLoader callerClassLoader()
   Answers the class loader of the method that called the caller.

static void shutdown()
   The vm must invoke this method when all other threads have been
   shutdown.  This is the final shutdown sequence.

static void closeJars()
   Informs the VM that the class libs opened a JAR cache, and a call
   to close the cache should be made during VM shutdown sequence.

static void deleteOnExit()
   Informs the VM that the class libs have created some 'delete on exit'
   tasks, and a call to invoke the tasks should be made during the VM
   shutdown sequence.


The SystemProcess class is simply the concrete implementation of the
java.lang.Process abstract class.  It is used in the implementation of
Runtime#exec() methods.

As I said before, there  are other VM-specific classes that are entirely
the responsibility of the VM developer (e.g. Class, Thread, etc.) and
these are covered by regular Java API specifications.

A few classes are predominantly common (i.e. reusable) code.  VM
developers can choose to either implement the entire class, or pick up
the common code and implement one or two methods to complete them (e.g.
AccessController, and String).

Regards,
Tim

>> If there is an interest, we can share the interface we are using and
>> evolve it as part of harmony.  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 (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>>
>> Archie Cobbs wrote:
>>
>>> Geir Magnusson Jr. wrote:
>>>
>>>
>>>>>> Ok, from the school of "Storming the Gates! Take 2", lets again
>>>>>> examine the question of VM/classlib interface as this is an
>>>>>> important  aspect to address and our first run at it wasn't so
>>>>>> successful.
>>>>>> The questions I have are all around the different ways has this
>>>>>> been  done.  So far we know about GNU Classpath, but I assume   there
>>>>>> are  others.  What I'm specifically interested in is :
>>>>>>    - what were the architectural goals
>>>>>>    - what mistakes made in the past did you try to avoid
>>>>>>    - what are the known limitations
>>>>>>    - does the interface support our target version of 1.5
>>>>>>
>>>>>>
>>>>>
>>>>> Just my opinion: I don't think the VM/classlib API matters that  much.
>>>>>
>>>>>
>>>> Seriously... I've never done VM work, but system-level work that I
>>>> have done can live or die based on the API, for all sorts of  reasons,
>>>> like performance, the ability to elegantly evolve over time, etc.
>>>>
>>>
>>>
>>> I think you're right -- in general -- that API design can have a  major
>>> impact on things. I'm just saying that in this specific case it  doesn't
>>> look like it's so critical (to me).
>>>
>>>
>>>>> The API is private to the VM implementation, so the only effect  it
>>>>> can
>>>>> have on application code is how efficient it is.
>>>>>
>>>>
>>>>
>>>> The API isn't private to the VM implementation, is it?  The
>>>> _implementation_ of the API is, but not the API itself - that's a
>>>> contract between the classlib and VM...
>>>>
>>>
>>>
>>> You're confusing two things: the API that applications use (which
>>> is strictly a Java API you can read about via Javadoc) and the API
>>> that the class library uses, via native method calls, to talk  directly
>>> to the VM. The latter is not publicly visible (and usually VM 
>>> specific).
>>>
>>> Now, there may be public methods such as Thread.start() that just
>>> happen to be implemented via native method calls directly into the
>>> VM, but those are degenerate cases. The application doesn't "know"
>>> that things happen to be implemented that way and that it might be
>>> making a direct native call into the VM.
>>>
>>> By the way, Classpath avoids any such degenerate cases: all methods
>>> in class Foo that could be native instead are called through a
>>> "liason" class VMFoo. So all of the Classpath/VM API native methods
>>> are non-public. (This is why I said Classpath assumes the VM can
>>> do "easy" inlining, because of the Foo -> VMFoo extra hops).
>>>
>>> The API that applications use is defined by the public classes and
>>> methods in the class library. How those classes are implemented is
>>> not known to the application (and the application shouldn't care).
>>> Which ones actually involve calls into the VM is irrelevant.
>>>
>>> E.g., have you ever seen the Javadoc for a method contain the
>>> "native" keyword? No -- that keyword is stripped out because it's
>>> irrelevant from an API point of view (so is "synchronized").
>>> Instead, those are implementation details.
>>>
>>> The application just sees a big Java class library. The class library
>>> sees a handful of native methods into the VM. The VM sees an
>>> operating system of some sort. Etc.
>>>
>>>
>>>> For example, when people were porting their platforms to use GNU
>>>> Classpath's API, what did they think?  Did they have to redo  anything
>>>> internally?
>>>>
>>>
>>>
>>> In my experience, things mostly made sense, but there were definitely
>>> some problems. However, they were there more because nobody had  gotten
>>> around to fixing them, rather than some conflict of API design vision
>>> or anything like that.
>>>
>>> For example, the API call to load native libraries didn't have a
>>> ClassLoader parameter. But that is required to properly implement
>>> Java 2 style class loading (and unloading). So we added one. There
>>> was nothing controversial about it. Similarly for lots of other  stuff.
>>>
>>> In other words, there hasn't been much debate on the Classpath lists
>>> about APIs. It's pretty straightforward, and in for the most part the
>>> little details don't matter that much anyway. This is why many of  us
>>> who
>>> work on Classpath are wondering why anyone would bother wondering how
>>> to reinvent the wheel, when the wheel already rolls just fine :-)
>>>
>>> Cheers,
>>> -Archie
>>>
>>> _____________________________________________________________________
>>> _____
>>> Archie Cobbs      *        CTO, Awarix        *      http://
>>> www.awarix.com
>>>
>>>
>>
>>
> 

-- 

Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

Mime
View raw message