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 delegating VM function (was: Re: Eclipse part 2)
Date Mon, 25 Jul 2005 17:50:35 GMT
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.



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.p.ellison@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.
>>Mark Wielaard wrote:
>>>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 
>>>>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
>>>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.
>>Tim Ellison (t.p.ellison@gmail.com)
>>IBM Java technology centre, UK.


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

View raw message