harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David P Grove <gro...@us.ibm.com>
Subject Re: Eclipse part 2
Date Mon, 25 Jul 2005 13:13:06 GMT
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.
> 
> 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.


Mime
View raw message