You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Santiago Gala <sg...@apache.org> on 2005/06/06 00:26:23 UTC
Re: [arch] How much of java.* and friends does Harmony need
towrite. Was: VM/Classlibrary interface
El dom, 05-06-2005 a las 01:56 -0500, Dan Lydick escribió:
(...)
>
> I suppose I need to do some more homework then.
> If GNU Classpath is used without modification for
> numerous VM's, then great! Ultimately, what I am
A few classes need to be modified:
- jamvm (from README): "A number of classes are reference classes which
must be modified for a particular VM. These are provided and built
along with JamVM (see INSTALL). JamVM 1.3.0 works with Classpath
version 0.14 (the latest development snapshot). It should also work
with the latest version direct from CVS (but check the Classpath
mailing lists for possible patches). Later snapshots of Classpath may
also work, if no modifications have been made to the VM interface."
- jikesRVM fetches classpath from cvs, and allows you to put your own
copy instead, to build the boot image. In addition, it implements or
modifies, glancing at cvs code, gnu.classpath.(VMStackWalker.java|
VMSystemProperties.java) and a bunch of classes (VM) in java.(lang|io|
net|util).VM* (including also Object, Thread, Throwable .ref.*,
some .reflect. classes)
- sableVM (1.11.3) bundles a version of classpath with it, numbered
after the sableVM release. I'm not sure how modified it is WRT CVS
classpath, but the claim is "SableVM Classpath is based on GNU
Classpath 0.08 + further CVS changes" (INSTALL-DEVEL)
- not sure about other VMs
This is inconvenient for VM writers, as they must bundle or track the
development of those classes in both libraries.
I think that this is why there was a suggestion to isolate all
references in a separate "deliverable" (be it package, jar, bundle,
whatever), so that people working in different VMs can have independent
versioning and API changes than the library as a whole.
This will become specially handy as classpath grows, because the VM*
part will be fairly stable, but changes as implementation gets better
or new APIs (JSR) get approved will be big.
Regards
Santiago
--
Santiago Gala
High Sierra Technology, S.L.
http://memojo.com/blojsom/blog/sgala/
RE: [arch] Modules and interfaces (was: How much of java.* ...)
Posted by Renaud BECHADE <re...@numerix.com>.
＞> It brings to mind some of the portability/modularity issues we've been
＞> wrestling with (at great length) with MMTk and the interdependence
＞> between the memory manager and the VM. Our solution is not earth
＞> shattering, but it evolved out of a very long struggle with issues like
＞> the one Geir is alluding to above.
＞
＞I will most probably be told why not very shortly, but is it not
＞possible to use the class loader to solve this problem?
Indeed if you add some "AOP-like" code at the right place (check the
resource names, do something specific if it is VM-specific) it might just do
(at least conceptually). After all it is just possible to instrument classes
and add whatever code is required at runtime, so I guess the java.lang.*
classes do not really need to have everything available in the jar that is
exposed to users, except what is in the standards (the signatures, the code
itself is another question, right?).
Sound like mil. security principle: give people just what they need to do
their jobs, not more.
RB
-----Original Message-----
From: Matthew French [mailto:matthew@camary.co.za]
Sent: Wednesday, June 08, 2005 6:09 AM
To: harmony-dev@incubator.apache.org
Subject: Re: [arch] Modules and interfaces (was: How much of java.* ...)
On Tue, 2005-06-07 at 07:35 +1000, Steve Blackburn wrote:
> It brings to mind some of the portability/modularity issues we've been
> wrestling with (at great length) with MMTk and the interdependence
> between the memory manager and the VM. Our solution is not earth
> shattering, but it evolved out of a very long struggle with issues like
> the one Geir is alluding to above.
I will most probably be told why not very shortly, but is it not
possible to use the class loader to solve this problem?
My first solution would be too implement VM specific functions in their
own library, but using existing the namespaces, not creating new ones.
So you have your own java.lang.Thread, for example, that works with your
VM. The class loader then uses the VM specific functionality to override
the generic functionality.
This acts like a mask, hiding functionality that the VM authors decide
is specific to the VM, but leaving all the other generic functionality
exposed. This has the advantage that it reduces the amount of re-work
while allowing enormous flexibility. The only requirement is that the
class libraries call the public API instead of internal implementation
classes - i.e. make no assumptions about the implementation of any other
class (as much as possible, anyway).
This also makes it possible to inject, for example, a VM specific String
class, or specially tuned Socket classes. But at the same time for other
VM's to use the generic String class.
The principal can be extended so that application specific classes can
override the generic classes. Although this is wrong for so many other
reasons. :(
>>From a brief look at the classpath docs, it looks like classpath uses a
similar approach - from what I can tell the one I am suggesting is just
more generic.
Or is the issue deeper than this?
- Matthew
Re: [arch] Modules and interfaces (was: How much of java.* ...)
Posted by Matthew French <ma...@camary.co.za>.
On Tue, 2005-06-07 at 07:35 +1000, Steve Blackburn wrote:
> It brings to mind some of the portability/modularity issues we've been
> wrestling with (at great length) with MMTk and the interdependence
> between the memory manager and the VM. Our solution is not earth
> shattering, but it evolved out of a very long struggle with issues like
> the one Geir is alluding to above.
I will most probably be told why not very shortly, but is it not
possible to use the class loader to solve this problem?
My first solution would be too implement VM specific functions in their
own library, but using existing the namespaces, not creating new ones.
So you have your own java.lang.Thread, for example, that works with your
VM. The class loader then uses the VM specific functionality to override
the generic functionality.
This acts like a mask, hiding functionality that the VM authors decide
is specific to the VM, but leaving all the other generic functionality
exposed. This has the advantage that it reduces the amount of re-work
while allowing enormous flexibility. The only requirement is that the
class libraries call the public API instead of internal implementation
classes - i.e. make no assumptions about the implementation of any other
class (as much as possible, anyway).
This also makes it possible to inject, for example, a VM specific String
class, or specially tuned Socket classes. But at the same time for other
VM's to use the generic String class.
The principal can be extended so that application specific classes can
override the generic classes. Although this is wrong for so many other
reasons. :(
>>From a brief look at the classpath docs, it looks like classpath uses a
similar approach - from what I can tell the one I am suggesting is just
more generic.
Or is the issue deeper than this?
- Matthew
[arch] Modules and interfaces (was: How much of java.* ...)
Posted by Steve Blackburn <St...@anu.edu.au>.
Geir Magnusson Jr. wrote:
> Doesn't this imply that the GNU Classpath interface should add a
> second API that *it* should comply with for symmetry? That way you
> don't get dependencies on GNU Classpath internals?
I've been a bystander in this discussion as I know very little about the
class library issues. There were obviously a lot of concerns being
discussed in this thread, but I'd just like to respond briefly to the
above...
It brings to mind some of the portability/modularity issues we've been
wrestling with (at great length) with MMTk and the interdependence
between the memory manager and the VM. Our solution is not earth
shattering, but it evolved out of a very long struggle with issues like
the one Geir is alluding to above.
In the end, our "interface" is not in the form of a simple API, but of
reciprocal packages implemented on the MM and VM sides of the fence.
So we have org.mmtk.vm, which captures all VM-specific dependencies,
leaving the rest of MMTk's packages (the bulk of the code) strictly
VM-neutral.
We have a generic template implementation of the org.mmtk.vm package
which serves to define the interface, and against which a VM-neutral
mmtk.jar is built. Each VM then provides a VM-specific implementation
of this package which binds into that VM's services (such as the way
that VM identifies roots for collection, supports mmap(), defines the
size of an address, or whatever...).
At this stage we only have one example in cvs, but there are two others
in various states of development (jnode, which is actively being
developed & Rotor which is a little out of date right now).
http://cvs.sourceforge.net/viewcvs.py/jikesrvm/MMTk/ext/vm/
(the stub directory defines the package abstractly, the JikesRVM
directory has the Jikes RVM - specific implementation)
We want this to be symmetric, so that the VM has a similar arrangement
whereby it can support various memory managers by having each of them
implement some package. We have not yet cleaned up this aspect of Jikes
RVM, but it is on our short list of planned cleanups. MOre generally,
we want to use this model in a complete componentization of Jikes RVM.
--Steve
Re: [arch] How much of java.* and friends does Harmony need towrite. Was: VM/Classlibrary interface
Posted by "Geir Magnusson Jr." <ge...@apache.org>.
On Jun 6, 2005, at 10:01 AM, Aaron Hamid wrote:
> Gah. :(
>
> So if I am to understand this correctly: Classpath java.lang.*
> implementation does not rely on specifics of any given VM*
> interface implementation, but said VM* interface implementations
> MAY rely on internals of existing Classpath java.lang.* classes?
> (so there is a one-way dependency from the VM* implementation to
> Classpath but not vice-versa, hence the "out of the box" claims?)
> And through deduction, "standardizing" this VM* interface would
> also entail "standardizing" reverse access to the class lib
> java.lang.* implementations (either through some informal agreement
> on package visibility members *yuck*, or through a more
> sophisticated, but more cumbersome, API)?
Doesn't this imply that the GNU Classpath interface should add a
second API that *it* should comply with for symmetry? That way you
don't get dependencies on GNU Classpath internals?
geir
>
> Aaron
>
> Jeroen Frijters wrote:
>
>> You're missing the fact that moving these classes into another
>> packages
>> creates another problem that is much worse. Namely that you often
>> need
>> to access private state in the public classes, you can do that by
>> living
>> in the same package, that's why the VM* classes live in the same
>> package
>> as their public counterpart.
>>
>
> Sven de Marothy wrote:
>
>> On Mon, 2005-06-06 at 00:26 +0200, Santiago Gala wrote:
>>
>>> A few classes need to be modified:
>>>
>> You're a bit confused here. Of course the Classpath VM interface
>> requires the VM to provide certain classes. How else would it work?
>> That does not mean to say that classpath itself needs modification
>>
>
>
--
Geir Magnusson Jr +1-203-665-6437
geirm@apache.org
Re: [arch] How much of java.* and friends does Harmony
need towrite. Was: VM/Classlibrary interface
Posted by Sven de Marothy <sv...@physto.se>.
On Mon, 2005-06-06 at 10:01 -0400, Aaron Hamid wrote:
> Gah. :(
>
> So if I am to understand this correctly: Classpath java.lang.* implementation
> does not rely on specifics of any given VM* interface implementation, but said
> VM* interface implementations MAY rely on internals of existing Classpath
> java.lang.* classes? (so there is a one-way dependency from the VM* implementation
> to Classpath but not vice-versa, hence the "out of the box" claims?)
Please read:
Classpath VM integration guide.
http://www.gnu.org/software/classpath/docs/vmintegration.html#SEC3
See also the reference implementation of the VM classes Classpath
requires:
http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/vm/reference/java/lang/
/Sven
Re: [arch] How much of java.* and friends does Harmony need towrite.
Was: VM/Classlibrary interface
Posted by Aaron Hamid <ar...@cornell.edu>.
Gah. :(
So if I am to understand this correctly: Classpath java.lang.* implementation does not rely on specifics of any given VM* interface implementation, but said VM* interface implementations MAY rely on internals of existing Classpath java.lang.* classes? (so there is a one-way dependency from the VM* implementation to Classpath but not vice-versa, hence the "out of the box" claims?) And through deduction, "standardizing" this VM* interface would also entail "standardizing" reverse access to the class lib java.lang.* implementations (either through some informal agreement on package visibility members *yuck*, or through a more sophisticated, but more cumbersome, API)?
Aaron
Jeroen Frijters wrote:
> You're missing the fact that moving these classes into another packages
> creates another problem that is much worse. Namely that you often need
> to access private state in the public classes, you can do that by living
> in the same package, that's why the VM* classes live in the same package
> as their public counterpart.
Sven de Marothy wrote:
> On Mon, 2005-06-06 at 00:26 +0200, Santiago Gala wrote:
>>A few classes need to be modified:
>
> You're a bit confused here. Of course the Classpath VM interface
> requires the VM to provide certain classes. How else would it work?
>
> That does not mean to say that classpath itself needs modification
Re: [arch] How much of java.* and friends does Harmony need towrite. Was: VM/Classlibrary
interface
Posted by David P Grove <gr...@us.ibm.com>.
>From a user perspective, Jikes RVM uses classpath "out of the box". (It
builds with unmodified GNU classpath releases and classpath cvs head; we
don't distribute GNU classpath with Jikes RVM).
We do provide our own versions of a few classes in java.* that the build
process selects instead of using the classpath ones, but if that's the
definition of not using classpath out of the box, then I'm not sure anyone
actually uses classpath out of the box.
--dave
> You're a bit confused here. Of course the Classpath VM interface
> requires the VM to provide certain classes. How else would it work?
>
> That does not mean to say that classpath itself needs modification
>
> > - jamvm
>
> Uses Classpath out of the box.
>
> > - jikesRVM
>
> Does not. It did not use Classpath originally, and hasn't migrated fully
> to the Classpath VM interface.
>
> > - sableVM (1.11.3)
>
> Uses Classpath out of the box. SableVM bundles it's own Classpath for
> practicality, and because they want some things slightly different. It
> can still use Classpath out of the box if you want that.
>
> Out of your three examples, two can use Classpath straight out of the
> box. Only JikesRVM can't, and it was, after all, developed for an
> entirely different class library.
>
> > This is inconvenient for VM writers, as they must bundle or track the
> > development of those classes in both libraries.
>
> Yes. Changes to the class library<->VM interface are inconvenient.
>
> > I think that this is why there was a suggestion to isolate all
> > references in a separate "deliverable" (be it package, jar, bundle,
> > whatever),
>
> That's what the VM interface is for.
>
> /Sven
>
>
Re: [arch] How much of java.* and friends does Harmony need
towrite. Was: VM/Classlibrary interface
Posted by Sven de Marothy <sv...@physto.se>.
On Mon, 2005-06-06 at 00:26 +0200, Santiago Gala wrote:
> El dom, 05-06-2005 a las 01:56 -0500, Dan Lydick escribió:
> (...)
> >
> > I suppose I need to do some more homework then.
> > If GNU Classpath is used without modification for
> > numerous VM's, then great! Ultimately, what I am
>
> A few classes need to be modified:
You're a bit confused here. Of course the Classpath VM interface
requires the VM to provide certain classes. How else would it work?
That does not mean to say that classpath itself needs modification
> - jamvm
Uses Classpath out of the box.
> - jikesRVM
Does not. It did not use Classpath originally, and hasn't migrated fully
to the Classpath VM interface.
> - sableVM (1.11.3)
Uses Classpath out of the box. SableVM bundles it's own Classpath for
practicality, and because they want some things slightly different. It
can still use Classpath out of the box if you want that.
Out of your three examples, two can use Classpath straight out of the
box. Only JikesRVM can't, and it was, after all, developed for an
entirely different class library.
> This is inconvenient for VM writers, as they must bundle or track the
> development of those classes in both libraries.
Yes. Changes to the class library<->VM interface are inconvenient.
> I think that this is why there was a suggestion to isolate all
> references in a separate "deliverable" (be it package, jar, bundle,
> whatever),
That's what the VM interface is for.
/Sven