You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by netsql <ne...@roomity.com> on 2005/07/21 19:21:02 UTC
Eclipse part 2
http://news.com.com/IBM+steps+into+open-source+Java+project/2100-7344_3-5798290.html?tag=nefd.top
.V
Re: delegating VM function (was: Re: Eclipse part 2)
Posted by 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
delegating VM function (was: Re: Eclipse part 2)
Posted by 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: Eclipse part 2
Posted by David P Grove <gr...@us.ibm.com>.
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.
Re: Eclipse part 2
Posted by Tim Ellison <t....@gmail.com>.
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.
Re: Eclipse part 2
Posted by Mark Wielaard <ma...@klomp.org>.
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
Re: Eclipse part 2
Posted by Tim Ellison <t....@gmail.com>.
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].
Regards,
Tim
[1] http://www.ibm.com/developerworks/java/jdk/
[2] http://www.ibm.com/embedded
Michael Haupt wrote:
> Hi,
>
> that's good news. :-)
>
> Does IBM have an in-house implementation of the standard libraries
> that could be released under ASL? Or is the IBM JDK delivered with the
> Sun libraries?
>
> Greetings,
>
> Michael Haupt
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: Eclipse part 2
Posted by Michael Haupt <mh...@gmail.com>.
Hi,
that's good news. :-)
Does IBM have an in-house implementation of the standard libraries
that could be released under ASL? Or is the IBM JDK delivered with the
Sun libraries?
Greetings,
Michael Haupt
Re: Eclipse part 2
Posted by usman bashir <gr...@gmail.com>.
yeah and i am seeing many more to come, but we need a direct goal to avoid
the "rough edges" but i hope it will take time though!!
On 7/22/05, Peter Donald <pe...@realityforge.org> wrote:
>
> Good work Geir and whoever else is working away behind the scenes. This
> is great news!
>
> Geir Magnusson Jr. wrote:
> > This is an Apache project :)
> >
> > On Jul 21, 2005, at 1:21 PM, netsql wrote:
> >
> >> http://news.com.com/IBM+steps+into+open-source+Java+project/
> >> 2100-7344_3-5798290.html?tag=nefd.top
> >>
> >> .V
> >>
> >>
> >
>
>
>
--
Usman Bashir
Certified IBM XML Solution Developer
Certified UML Developer
Brainbench Certified Internet Perfessional[advance](BCIP)
Brainbench Certified Java Perfessional (BCJP)
Brainbench Certified .NET Perfessional
Brainbench Ceritified C++ Perfessional (BCCP)
Software engineer IT24
Faculty Member Operation Badar Lahore
Re: Eclipse part 2
Posted by Peter Donald <pe...@realityforge.org>.
Good work Geir and whoever else is working away behind the scenes. This
is great news!
Geir Magnusson Jr. wrote:
> This is an Apache project :)
>
> On Jul 21, 2005, at 1:21 PM, netsql wrote:
>
>> http://news.com.com/IBM+steps+into+open-source+Java+project/
>> 2100-7344_3-5798290.html?tag=nefd.top
>>
>> .V
>>
>>
>
Re: Eclipse part 2
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
This is an Apache project :)
On Jul 21, 2005, at 1:21 PM, netsql wrote:
> http://news.com.com/IBM+steps+into+open-source+Java+project/
> 2100-7344_3-5798290.html?tag=nefd.top
>
> .V
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org