delegating VM function (was: Re: Eclipse part 2)

[Tim Ellison <t....@gmail.com>]

That sounds like a perfectly reasonable pattern.  Graeme's earlier
description [1] is a coarse grained approach, which says if the class
has a close VM dependency then we leave it up to the VM-implementor to
provide it ;-)  For types like Object that is not onerous since there is
not much behavior in the common code, but I can see that, say, String
has enough reusable code that externalizing the VM part into a VMString
type makes sense rather than copying another impl.

[1]
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200507.mbox/%3cOFCD7E9468.8263BA61-ON8525703D.005CCAC9-8525703D.0060E73F@ca.ibm.com%3e


Regards,
Tim


David P Grove wrote:
> Yes.  The main focus of the Jikes RVM project is VM/JIT research.  We've 
> made minor contributions to the design of the GNU classpath VM/classlib 
> interface, since we are one of the many runtimes that depend on it, but 
> we're mainly consumers of class libraries, not producers. As discussed in 
> more detail in the paper Mark cited below, Jikes RVM did switch from the 
> OTI libraries to GNU Classpath in 2002/2003.  The switch was made both 
> because GNU classpath was open source, and this more available to our 
> users, and because at the time, GNU classpath provided the functionality 
> we needed to be able to run Eclipse on Jikes RVM. 
> 
> In my opinion, the main thing to learn from the GNU classpath library 
> interface is that the pattern of having a Foo.java which delegates any 
> potentially VM-specific functionality to a VMFoo.java works quite nicely. 
> In classpath this has evolved to include all native methods being defined 
> on VMFoo classes instead of on Foo directly.  GNU classpath supports a 
> fairly diverse set of client runtimes and this pattern developed as the 
> most natural way for letting various runtimes provide customized, 
> high-performance implementations of the VM-specific functionality. 
> 
> The last time this came up, the discussion quickly devolved into an 
> argument about whether the package prefix should be java.lang.VMFoo or 
> org.harmony.vm.lang.VMFoo.  I personally think both sides had some valid 
> points, but to me the package prefix is actually a secondary issue  (and 
> one could hope that JSR 277 would eventually provide better mechanisms to 
> provide unsafe APIs to the internals of the class libraries while 
> preventing them from being used directly by general applications.  GNU 
> Classpath does this by using basic Java language mechanisms (VMFoo classes 
> are package scoped), other VMs do it via classloader hackery. IMO neither 
> option is very satisfying.). 
> 
> The main point is that for maximal flexibility and performance the class 
> libraries should talk to the VM through a well-specified, Java-only 
> interface.  Don't assume that the VM would prefer being talked to by the 
> class libraries via native methods, or a struct of "C" function pointers. 
> If this is true for a VM, then it can implement the VMFoo classes with a 
> trivial wrapper implementation that does exactly that (one could even be 
> provided as part of the class libraries; GNU classpath provides default 
> implementations of most of its VMFoo classes that use native methods/JNI). 
> 
> 
> --dave
> 
> Tim Ellison <t....@gmail.com> wrote on 07/24/2005 04:11:25 PM:
> 
> 
>>Indeed.  IBM has multi and varied interests in all aspects of Java.  I
>>think of the Jikes folk as VM developers rather than class library
>>developers, but I may be doing them an injustice because I'm not
>>familiar with their classpath contributions.
>>
>>Regards,
>>Tim
>>
>>
>>Mark Wielaard wrote:
>>
>>>Hi,
>>>
>>>On Fri, 2005-07-22 at 11:44 +0100, Tim Ellison wrote:
>>>
>>>
>>>>There are two distinct groups within IBM doing class library work --
>>>>hey, it's a big place!
>>>>
>>>>One group provides a robust J2SE based on the Sun libraries for many 
> 
> IBM
> 
>>>>products/platforms [1].  The other group has no access to Sun code and
>>>>provides a (similarly robust <g>) smaller set of IBM-authored 
> 
> libraries
> 
>>>>for embedded product offerings [2].
>>>
>>>
>>>You seem to forget group 3 (wow, IBM is big!) that produced JikesRVM 
> 
> and
> 
>>>that actually switched from those robust IBM-authored libraries to GNU
>>>Classpath <double g!> :)
>>>
>>>IBM research published an interesting paper about this that is worth a
>>>read.
>>>
>>>The Jikes Research Virtual Machine project: Buliding an open-source
>>>research community
>>>B. Alpern, S. Augart, S.M. Blackburn, M. Butrico, A. Cocchi, P Cheng, 
> 
> J.
> 
>>>Dolby, S. Fink, D. Grove, M. Hind, K.S. McKinley, M. Mergen, J.E.B.
>>>Moss, T. Ngo, V. Sarkar, and M. Trapp. 
>>>IBM Systems Journal, Vol 44, No 2, 2005.
>>>
>>>http://www.research.ibm.com/journal/sj/442/alpern.pdf
>>>
>>>Cheers,
>>>
>>>Mark
>>
>>-- 
>>
>>Tim Ellison (t.p.ellison@gmail.com)
>>IBM Java technology centre, UK.
> 
> 
> 

-- 

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

Re: delegating VM function (was: Re: Eclipse part 2)

[David P Grove <gr...@us.ibm.com>]

I was reminded off-list that Jikes RVM's use of GNU classpath's VM/library 
interface was more complex than I'd described in my previous note.  The 
Foo/VMFoo works quite nicely for us in many cases, especially when the 
VMFoo class is a holder for VM-specific static methods (eg, VMRuntime, 
VMSystem, VMString, VMDouble).  Jikes RVM don't use it for truly core 
classes like java.lang.ref.*, java.lang.Class, java.lang.Thread, or 
java.lang.Throwable where we want more control over the instance fields of 
the object and/or don't want to incur an extra indirect to get to 
VM-specific instance data.

Also, GNU classpath doesn't (can't) provide a working reference 
implementation for every method of every VMFoo class (or even a few other 
classes like java.lang.reflect.Method and its ilk), so the distinction 
between its interface and the kernel approach Graeme and Tim described is 
more a matter of degree and naming convention as opposed to a sharp 
difference.  GNU classpath has a smaller set of mandatory kernel classes 
that the VM must provide, and also has a "policy" that native methods get 
segregated into separate classes (which is good for whacky VM's like Jikes 
RVM that aren't implemented in C, and isn't supposed to hurt  C-based VM's 
assuming reasonable levels of inlining). 

--dave