You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Weldon Washburn <we...@gmail.com> on 2006/02/10 20:53:58 UTC
[jchevm] porting harmony classlib to JCHEVM
Archie Cobbs,
Do you know if anyone is working on a port of Harmony Classlib to
JCHEVM? If false, I would like to start this port. I can't guarantee
I have time to finish the port but intend to at least sketch out what
needs to be done so that others can join the effort.
I have started looking at JCHEVM to figure out how to glue the Harmony
Classlibrary kernel classes (see
…modules/kernel/src/main/java/java/lang/*.java) to the native entry
points listed in jchevm/libjc/native_lib.c. The goal is to make only
absolutely essential mods to JCHEVM code. Ideally, there would be
zero changes to JCHEVM. All the "glue" would reside in JCHEVM's
private copy of Classlib's kernel classes.
Looking at Classlib's Class.java, about 17 of 40 APIs look to be a
simple conversion of a virtual method to a static method that takes a
"this ptr" as its first parameter. For example, the method isArray()
in Class.java would be modified to look like the code below. This
modified Class.java file would reside somewhere in the JCHEVM tree.
The original Class.java file in the Harmony Classlib tree would remain
untouched.
// Harmony/modules/kernel/src/main/java/java/lang/Class.java
Public boolean isArray () {
Boolean bb = VMClass.wrapperIsArray(this);
Return bb;
}
Because the wrapper is adding a layer of identically named methods and
thus potentially really confusing the name space, I renamed
java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray().
All the enties in _jc_ilib_table[ ] would also be "decorated" with
"wrapper".
Thoughts?
Thanks
Weldon
--
Weldon Washburn
Intel Middleware Products Division
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> I agree with most everything you said below. The Thread class is
> indeed tricky. I can't look at GNU Classpath code as I am doing this
> port. I want "kernel_path" to be Apache licensed and not a GPL
Not looking is certainly a safe approach, but make sure you don't
unnecessarily restrict yourself. Re-implemnting an algorithm "in your
own words" is not a copyright violation. And certainly there's less
at stake with Classpath code than e.g. looking at Sun's code.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Weldon Washburn <we...@gmail.com>.
Archie,
I agree with most everything you said below. The Thread class is
indeed tricky. I can't look at GNU Classpath code as I am doing this
port. I want "kernel_path" to be Apache licensed and not a GPL
derivative. I am only looking at the native entry points to JCHEVM.
So I can't benefit from what was learned about synch code in Classpath
Thread class. I may need your help to tell me what is going on in
java_lang_VMThread.c as I will need to match up Thread object fields
that are accessed via _JC_VMFIELD.
I think the approach taken by Harmony Classlibrary is that they intend
the kernel classes to be rewritten by the VM implementer so that the
VM design is not constrained by Classlibrary decisions. Of course,
the price of the architectural decision is that one has to rewrite
kernel classes for each new VM. I have found the boundaries for
kernel classes quite clear and easy to navigate.
-- Weldon
PS -- I am modifying a copy of Classpath kernel sub-tree. I renamed
it "kernel_path". I intend to donate the kernel_path code in the next
few days. Perhaps you can help me figure out where to put it. Once
donated, we can use it to discuss the next steps for completing the
port.
On 2/11/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Geir Magnusson Jr wrote:
> >> I like your idea of zero mods to JCHEVM. I will attempt to localize
> >> all mods to Classlibrary's Kernel Classes. Maybe this set of modified
> >> Kernel Classes could be used by any VM that runs GNU Classpath.
> >
> > I assume you're talking about making a "glue layer" that the standard
> > Harmony Classlibrary can work with?
>
> Yes..
>
> >> will try some experiments with java class name space to see if we can
> >> create wrappers that satisfy all the stakeholders.
> >
> > TO me, the ideal is to have a very clear demarcation of what is the
> > Harmony Classlibrary VM interface.
> >
> > So I'd see
> >
> > Harmony VM Interface
> > --------------------------
> > Harmony/Classpath Adapter
> > --------------------------
> > JCHEVM
> >
> > Is this what you mean?
>
> Yes.. that's the basic near term idea... (although technically if
> the adapter is written in Java (as we've discussed) then the Harmony
> VM interface is not really a VM interface).
>
> However I think ideally Classlib's API should be implemented to be equal
> Classpath's API. That may sound strange so let me try to explain why.
>
> The state of things now is that the VM API defined by Classlib
> is, well, not very well defined :-)
>
> Compare Classlib's Thread.java:
>
> trunk/modules/kernel/src/main/java/java/lang/Thread.java
>
> with these files from Classpath:
>
> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup
> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup
>
> Note every method in Classlib's Thread.java is: "return null". On the other
> hand, Classpath's API is much more complete and fully developed,
> race conditions have been analyzed and handled, SecurityManager implications
> have been taken into account, etc. To get Classlib to the same level,
> you'd have to duplicate a whole bunch of (at times very tricky and subtle)
> work -- not only implementing the API, but figuring out what the right API
> is -- that's already been figured out over several years in Classpath.
>
> In short there is lots of unimplemented stuff remaining in Classlib's
> existing API. From a simple argument of expediency, not to mention the
> benefits for debugging previously mentioned, adopting the "already baked"
> Classpath API makes lots of sense.
>
> For example: if there's more than one Harmony VM, you'd have to have a
> different version of the complicated adapter "glue" for each one.
> Instead, why not write the glue once, include it as part of Classlib,
> and make the "VM interface" really be a native interface, instead of a
> big "grey area". Plus there's already a working example of what the glue
> should look like to base it on.
>
> There's also this important principle lurking here, which has been learned
> over the years in Classpath: if there's a choice between implementing
> something in Java or forcing the VM to implement it, it's almost always
> preferable to implement it in Java. Java is much easier to debug, and you
> only have to debug it once - not N times for each of N VM implementations.
>
> FYI, the Classpath Java/VM API is defined by the files in this subtree:
>
> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/?root=classpath
>
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Weldon Washburn <we...@gmail.com>.
Archie,
Below is the README.txt that I intend to include with the (very) rough
glue layer. The whole glue layer is currently 350KB. I am not
certain if this donation needs to be a bulk contribution. Most of the
350KB derives from existing Apache Harmony code. Also, I don't want
to check all these files into source code control until we have a
clear understanding where they need to reside and how we want the
directories arranged.
The README.txt:
------------------------------------------------------------
Feb 11, 2006
Weldon Washburn, Intel
The code in this tree is very new. It has not been compiled.
This tree, kernel_path, is a generic adapter that will glue the
Apache Harmony Class Library to any Java Virtual Machine that
runs GNU Classpath.
The first JVM that kernel_path will run on is Harmony JCHEVM. It
is located at:
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/jchevm/
Directions for obtaining a copy of Harmony Class Library are at:
http://incubator.apache.org/harmony/subcomponents/classlibrary/build_classlib.html
In the Harmony Class Library tree is a document describing how to connect the
libraries to a new Java Virtual Machine. These directions are located
in the tree at:
....../Harmony/doc/kernel/kernel.txt
kernel.txt states:
The Kernel Java classes are those classes which are tied to the structure
of the VM, or whose structure is known by the VM. Most of these classes
are defined by the Java 1.4.2 API specification. The IBM VM implementations
of these classes are provided in open source. The IBM implementations
rely on the presence of (typically) VM specific natives to implement the
required Java APIs. Other VM writers can choose to use these implementations,
but this forces the writer to use the reference design and the writer must
then implement the natives, for which minimal documentation is provided.
The kernel_path directory is a copy of the following Harmony Class
Library sub-tree:
...../Harmony/modules/kernel
To reduce clutter, the svn directories and files have been removed
from kernel_path.
The original directory structure remains unchanged. Current status of
these files:
kernel_path/VM_native_stubs contains the java declaration of JCHEVM's
native method
entry points. These are java source files that correspond to _jc_ilib_table [ ]
that is defined in:
http://svn.apache.org/viewcvs.cgi/incubator/harmony/enhanced/jchevm/libjc/native_lib.c
VM_native_stubs files are probably 50% complete. Nothing has been compiled.
Most of the mods were done to the kernel_path/src/main/java/java/lang directory.
This directory is probably 20% complete. Nothing has been compiled.
Probably the
hardest file to get right will be j/j/l/Thread.java.
None of the following files have been modified yet:
kernel_path/src/main/java/java/lang/ref
kernel_path/src/main/java/java/lang/reflect
kernel_path/src/main/java/com/ibm/oti/vm
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Archie Cobbs wrote:
> Geir Magnusson Jr wrote:
>>> The state of things now is that the VM API defined by Classlib
>>> is, well, not very well defined :-)
>>
>> That's not actually true. We may be missing documentation or
>> something, but the Harmony Classlib VM API is a well-tested production
>> API used by IBM in their commercial VM offerings.
>>
>> Hard to argue with that.
>>
>> That's why the IBM J9 VM that was offered for evaluation purposes just
>> works.
>
> My understanding from Weldon's emails is that while it's true that
> Classlib runs on J9, that's true because J9 provides its own "glue" for
> Classlib to make things work. To make Classlib run on any other VM,
> there would still be a lot of work that needs to be done, which
> fortunately Weldon is already forging ahead on (if you don't believe
> me, compare the two java.lang.Thread classes I mentioned (Classpath's
> and Classlib's) for example).
>
> My comment is simply that there would be *lots* of benefits if the
> bottom of this glue layer we're developing is the same as the VM API
> that Classpath uses, and moreover this is actually the easiest path
> to take anyway.
>
I agree that having something (whatever - glue, tape, twine, spit,
bubblegum...) that lets GNU Classpath-using VMs just plug into Apache
Harmony's Classlib would be just peachy...
I just want to make sure that we know everything surrounding the VM
interface to the Classlib...
geir
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
>
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr wrote:
>> The state of things now is that the VM API defined by Classlib
>> is, well, not very well defined :-)
>
> That's not actually true. We may be missing documentation or something,
> but the Harmony Classlib VM API is a well-tested production API used by
> IBM in their commercial VM offerings.
>
> Hard to argue with that.
>
> That's why the IBM J9 VM that was offered for evaluation purposes just
> works.
My understanding from Weldon's emails is that while it's true that
Classlib runs on J9, that's true because J9 provides its own "glue" for
Classlib to make things work. To make Classlib run on any other VM,
there would still be a lot of work that needs to be done, which
fortunately Weldon is already forging ahead on (if you don't believe
me, compare the two java.lang.Thread classes I mentioned (Classpath's
and Classlib's) for example).
My comment is simply that there would be *lots* of benefits if the
bottom of this glue layer we're developing is the same as the VM API
that Classpath uses, and moreover this is actually the easiest path
to take anyway.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
build problems (was: Re: [jchevm] porting harmony classlib to JCHEVM)
Posted by Tim Ellison <t....@gmail.com>.
what build problems do you have?
Regards,
Tim
Weldon Washburn wrote:
> Tim,
> Good points below. I have a first cut at a kernel_path/Thread.java
> that glues Harmony Class Library to GNU Classpath compatible VM
> (jchevm). I will post it as soon as I get it to compile. Then we
> will have some code for a debate on what parts (if any) can be sucked
> into the baseline kernel/Thread.java. I am currently having problems
> getting the Class Library build system working.
> - Weldon
>
> On 2/15/06, Tim Ellison <t....@gmail.com> wrote:
>> Geir Magnusson Jr wrote:
>>> Archie Cobbs wrote:
>> <snip>
>>>> Compare Classlib's Thread.java:
>>>>
>>>> trunk/modules/kernel/src/main/java/java/lang/Thread.java
>>>>
>>>> with these files from Classpath:
>>>>
>>>> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup
>>>>
>>>> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup
>>>>
>>>>
>>>> Note every method in Classlib's Thread.java is: "return null". On the
>>>> other
>>>> hand, Classpath's API is much more complete and fully developed,
>>>> race conditions have been analyzed and handled, SecurityManager
>>>> implications
>>>> have been taken into account, etc. To get Classlib to the same level,
>>>> you'd have to duplicate a whole bunch of (at times very tricky and
>>>> subtle)
>>>> work -- not only implementing the API, but figuring out what the right
>>>> API
>>>> is -- that's already been figured out over several years in Classpath.
>>> Ok, I'm not sure what you are referring to. I know that our VM API is
>>> production tested on a certified, complete stack. I'm not sure where
>>> Classpath has been used in anger yet.
>>>
>>>> In short there is lots of unimplemented stuff remaining in Classlib's
>>>> existing API. From a simple argument of expediency, not to mention the
>>>> benefits for debugging previously mentioned, adopting the "already baked"
>>>> Classpath API makes lots of sense.
>>> We might be missing information from IBM on this. Tim?
>> Not sure what information you are expecting. Caveat: I've deliberately
>> not studied the Classpath VM interface code, so my understanding is limited.
>>
>> As Archie points out, the Harmony classlib code has a 'higher-level' VM
>> interface than Classpath. Taking his Thread example, in classlib the VM
>> implementor shows up with a full Thread implementation, and AIUI in
>> Classpath they are required to implement a VMThread type and can reuse
>> common code in Classpath's Thread.
>>
>> That's fine, and if Weldon or anyone else wants to create a version of
>> Thread that is implemented in terms of the same VMThread interface then
>> I say 'go for it'. (If Classpath were to dual license their code that
>> would be even better!)
>>
>> A while ago there was a discussion about the pro's and con's of
>> splitting Thread into common and VM-specific sections at all, even
>> before trying to agree on what goes where. We can go through that again
>> if people like. IMHO, saying 'show up with a working Thread' kinda
>> sidesteps that discussion, and people can implement it as they see fit.
>>
>> I have no problem with growing the classlib KERNEL stubs to have code
>> that VMs may choose to reuse. For example, you can imagine providing a
>> Java-based impl of TLS that some VMs would just want to use (or the
>> String.intern() as another example); but without imposing it on all VMs
>> that may choose to implement TLS|whatever as they see fit.
>>
>> So to close the loop -- I'm happy to share info, just not sure what you
>> want. If you want to know how IBM's VME implemented Thread then I can
>> take you down to a certain level at which point it becomes so
>> VM-specific that I'm not convinced it would help anyone.
>>
>> Regards,
>> Tim
>>
>> --
>>
>> Tim Ellison (t.p.ellison@gmail.com)
>> IBM Java technology centre, UK.
>>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Weldon Washburn <we...@gmail.com>.
Tim,
Good points below. I have a first cut at a kernel_path/Thread.java
that glues Harmony Class Library to GNU Classpath compatible VM
(jchevm). I will post it as soon as I get it to compile. Then we
will have some code for a debate on what parts (if any) can be sucked
into the baseline kernel/Thread.java. I am currently having problems
getting the Class Library build system working.
- Weldon
On 2/15/06, Tim Ellison <t....@gmail.com> wrote:
> Geir Magnusson Jr wrote:
> > Archie Cobbs wrote:
> <snip>
> >> Compare Classlib's Thread.java:
> >>
> >> trunk/modules/kernel/src/main/java/java/lang/Thread.java
> >>
> >> with these files from Classpath:
> >>
> >> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup
> >>
> >> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup
> >>
> >>
> >> Note every method in Classlib's Thread.java is: "return null". On the
> >> other
> >> hand, Classpath's API is much more complete and fully developed,
> >> race conditions have been analyzed and handled, SecurityManager
> >> implications
> >> have been taken into account, etc. To get Classlib to the same level,
> >> you'd have to duplicate a whole bunch of (at times very tricky and
> >> subtle)
> >> work -- not only implementing the API, but figuring out what the right
> >> API
> >> is -- that's already been figured out over several years in Classpath.
> >
> > Ok, I'm not sure what you are referring to. I know that our VM API is
> > production tested on a certified, complete stack. I'm not sure where
> > Classpath has been used in anger yet.
> >
> >>
> >> In short there is lots of unimplemented stuff remaining in Classlib's
> >> existing API. From a simple argument of expediency, not to mention the
> >> benefits for debugging previously mentioned, adopting the "already baked"
> >> Classpath API makes lots of sense.
> >
> > We might be missing information from IBM on this. Tim?
>
> Not sure what information you are expecting. Caveat: I've deliberately
> not studied the Classpath VM interface code, so my understanding is limited.
>
> As Archie points out, the Harmony classlib code has a 'higher-level' VM
> interface than Classpath. Taking his Thread example, in classlib the VM
> implementor shows up with a full Thread implementation, and AIUI in
> Classpath they are required to implement a VMThread type and can reuse
> common code in Classpath's Thread.
>
> That's fine, and if Weldon or anyone else wants to create a version of
> Thread that is implemented in terms of the same VMThread interface then
> I say 'go for it'. (If Classpath were to dual license their code that
> would be even better!)
>
> A while ago there was a discussion about the pro's and con's of
> splitting Thread into common and VM-specific sections at all, even
> before trying to agree on what goes where. We can go through that again
> if people like. IMHO, saying 'show up with a working Thread' kinda
> sidesteps that discussion, and people can implement it as they see fit.
>
> I have no problem with growing the classlib KERNEL stubs to have code
> that VMs may choose to reuse. For example, you can imagine providing a
> Java-based impl of TLS that some VMs would just want to use (or the
> String.intern() as another example); but without imposing it on all VMs
> that may choose to implement TLS|whatever as they see fit.
>
> So to close the loop -- I'm happy to share info, just not sure what you
> want. If you want to know how IBM's VME implemented Thread then I can
> take you down to a certain level at which point it becomes so
> VM-specific that I'm not convinced it would help anyone.
>
> Regards,
> Tim
>
> --
>
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Tim Ellison <t....@gmail.com>.
Geir Magnusson Jr wrote:
> Archie Cobbs wrote:
<snip>
>> Compare Classlib's Thread.java:
>>
>> trunk/modules/kernel/src/main/java/java/lang/Thread.java
>>
>> with these files from Classpath:
>>
>> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup
>>
>> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup
>>
>>
>> Note every method in Classlib's Thread.java is: "return null". On the
>> other
>> hand, Classpath's API is much more complete and fully developed,
>> race conditions have been analyzed and handled, SecurityManager
>> implications
>> have been taken into account, etc. To get Classlib to the same level,
>> you'd have to duplicate a whole bunch of (at times very tricky and
>> subtle)
>> work -- not only implementing the API, but figuring out what the right
>> API
>> is -- that's already been figured out over several years in Classpath.
>
> Ok, I'm not sure what you are referring to. I know that our VM API is
> production tested on a certified, complete stack. I'm not sure where
> Classpath has been used in anger yet.
>
>>
>> In short there is lots of unimplemented stuff remaining in Classlib's
>> existing API. From a simple argument of expediency, not to mention the
>> benefits for debugging previously mentioned, adopting the "already baked"
>> Classpath API makes lots of sense.
>
> We might be missing information from IBM on this. Tim?
Not sure what information you are expecting. Caveat: I've deliberately
not studied the Classpath VM interface code, so my understanding is limited.
As Archie points out, the Harmony classlib code has a 'higher-level' VM
interface than Classpath. Taking his Thread example, in classlib the VM
implementor shows up with a full Thread implementation, and AIUI in
Classpath they are required to implement a VMThread type and can reuse
common code in Classpath's Thread.
That's fine, and if Weldon or anyone else wants to create a version of
Thread that is implemented in terms of the same VMThread interface then
I say 'go for it'. (If Classpath were to dual license their code that
would be even better!)
A while ago there was a discussion about the pro's and con's of
splitting Thread into common and VM-specific sections at all, even
before trying to agree on what goes where. We can go through that again
if people like. IMHO, saying 'show up with a working Thread' kinda
sidesteps that discussion, and people can implement it as they see fit.
I have no problem with growing the classlib KERNEL stubs to have code
that VMs may choose to reuse. For example, you can imagine providing a
Java-based impl of TLS that some VMs would just want to use (or the
String.intern() as another example); but without imposing it on all VMs
that may choose to implement TLS|whatever as they see fit.
So to close the loop -- I'm happy to share info, just not sure what you
want. If you want to know how IBM's VME implemented Thread then I can
take you down to a certain level at which point it becomes so
VM-specific that I'm not convinced it would help anyone.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Archie Cobbs wrote:
> Geir Magnusson Jr wrote:
>> TO me, the ideal is to have a very clear demarcation of what is the
>> Harmony Classlibrary VM interface.
>>
>> So I'd see
>>
>> Harmony VM Interface
>> --------------------------
>> Harmony/Classpath Adapter
>> --------------------------
>> JCHEVM
>>
>> Is this what you mean?
>
> Yes.. that's the basic near term idea... (although technically if
> the adapter is written in Java (as we've discussed) then the Harmony
> VM interface is not really a VM interface).
>
> However I think ideally Classlib's API should be implemented to be equal
> Classpath's API. That may sound strange so let me try to explain why.
>
> The state of things now is that the VM API defined by Classlib
> is, well, not very well defined :-)
That's not actually true. We may be missing documentation or something,
but the Harmony Classlib VM API is a well-tested production API used by
IBM in their commercial VM offerings.
Hard to argue with that.
That's why the IBM J9 VM that was offered for evaluation purposes just
works.
>
> Compare Classlib's Thread.java:
>
> trunk/modules/kernel/src/main/java/java/lang/Thread.java
>
> with these files from Classpath:
>
> http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup
>
> http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup
>
>
> Note every method in Classlib's Thread.java is: "return null". On the other
> hand, Classpath's API is much more complete and fully developed,
> race conditions have been analyzed and handled, SecurityManager
> implications
> have been taken into account, etc. To get Classlib to the same level,
> you'd have to duplicate a whole bunch of (at times very tricky and subtle)
> work -- not only implementing the API, but figuring out what the right API
> is -- that's already been figured out over several years in Classpath.
Ok, I'm not sure what you are referring to. I know that our VM API is
production tested on a certified, complete stack. I'm not sure where
Classpath has been used in anger yet.
>
> In short there is lots of unimplemented stuff remaining in Classlib's
> existing API. From a simple argument of expediency, not to mention the
> benefits for debugging previously mentioned, adopting the "already baked"
> Classpath API makes lots of sense.
We might be missing information from IBM on this. Tim?
geir
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Archie Cobbs <ar...@dellroad.org>.
Geir Magnusson Jr wrote:
>> I like your idea of zero mods to JCHEVM. I will attempt to localize
>> all mods to Classlibrary's Kernel Classes. Maybe this set of modified
>> Kernel Classes could be used by any VM that runs GNU Classpath.
>
> I assume you're talking about making a "glue layer" that the standard
> Harmony Classlibrary can work with?
Yes..
>> will try some experiments with java class name space to see if we can
>> create wrappers that satisfy all the stakeholders.
>
> TO me, the ideal is to have a very clear demarcation of what is the
> Harmony Classlibrary VM interface.
>
> So I'd see
>
> Harmony VM Interface
> --------------------------
> Harmony/Classpath Adapter
> --------------------------
> JCHEVM
>
> Is this what you mean?
Yes.. that's the basic near term idea... (although technically if
the adapter is written in Java (as we've discussed) then the Harmony
VM interface is not really a VM interface).
However I think ideally Classlib's API should be implemented to be equal
Classpath's API. That may sound strange so let me try to explain why.
The state of things now is that the VM API defined by Classlib
is, well, not very well defined :-)
Compare Classlib's Thread.java:
trunk/modules/kernel/src/main/java/java/lang/Thread.java
with these files from Classpath:
http://cvs.savannah.gnu.org/viewcvs/classpath/java/lang/Thread.java?rev=1.17&root=classpath&view=markup
http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/java/lang/VMThread.java?rev=1.9&root=classpath&view=markup
Note every method in Classlib's Thread.java is: "return null". On the other
hand, Classpath's API is much more complete and fully developed,
race conditions have been analyzed and handled, SecurityManager implications
have been taken into account, etc. To get Classlib to the same level,
you'd have to duplicate a whole bunch of (at times very tricky and subtle)
work -- not only implementing the API, but figuring out what the right API
is -- that's already been figured out over several years in Classpath.
In short there is lots of unimplemented stuff remaining in Classlib's
existing API. From a simple argument of expediency, not to mention the
benefits for debugging previously mentioned, adopting the "already baked"
Classpath API makes lots of sense.
For example: if there's more than one Harmony VM, you'd have to have a
different version of the complicated adapter "glue" for each one.
Instead, why not write the glue once, include it as part of Classlib,
and make the "VM interface" really be a native interface, instead of a
big "grey area". Plus there's already a working example of what the glue
should look like to base it on.
There's also this important principle lurking here, which has been learned
over the years in Classpath: if there's a choice between implementing
something in Java or forcing the VM to implement it, it's almost always
preferable to implement it in Java. Java is much easier to debug, and you
only have to debug it once - not N times for each of N VM implementations.
FYI, the Classpath Java/VM API is defined by the files in this subtree:
http://cvs.savannah.gnu.org/viewcvs/classpath/vm/reference/?root=classpath
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Weldon Washburn wrote:
> Archie,
> I like your idea of zero mods to JCHEVM. I will attempt to localize
> all mods to Classlibrary's Kernel Classes. Maybe this set of modified
> Kernel Classes could be used by any VM that runs GNU Classpath.
I assume you're talking about making a "glue layer" that the standard
Harmony Classlibrary can work with?
I
> will try some experiments with java class name space to see if we can
> create wrappers that satisfy all the stakeholders.
TO me, the ideal is to have a very clear demarcation of what is the
Harmony Classlibrary VM interface.
So I'd see
Harmony VM Interface
--------------------------
Harmony/Classpath Adapter
--------------------------
JCHEVM
Is this what you mean?
geir
> - Weldon
>
> On 2/10/06, Archie Cobbs <ar...@dellroad.org> wrote:
>> Weldon Washburn wrote:
>>> Because the wrapper is adding a layer of identically named methods and
>>> thus potentially really confusing the name space, I renamed
>>> java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray().
>>> All the enties in _jc_ilib_table[ ] would also be "decorated" with
>>> "wrapper".
>> Is that really necessary? It seems to me that the existing JCHEVM
>> native API can remain intact.
>>
>> There are great advantages in being able to run JCHEVM with both
>> Classlib and Classpath at the same time for debugging purposes
>> (not to mention Classlib on J9). The more combinations you can
>> try, the easier it is to hone in on a bug's source. So I'd strongly
>> prefer that the Java/VM API remain the same as much as possible.
>> Certainly this can be done with the right "overlay" classes.
>>
>> Cheers,
>> -Archie
>>
>> __________________________________________________________________________
>> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>>
>
>
> --
> Weldon Washburn
> Intel Middleware Products Division
>
>
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> I like your idea of zero mods to JCHEVM. I will attempt to localize
> all mods to Classlibrary's Kernel Classes. Maybe this set of modified
> Kernel Classes could be used by any VM that runs GNU Classpath. I
> will try some experiments with java class name space to see if we can
> create wrappers that satisfy all the stakeholders.
Sounds great!
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Weldon Washburn <we...@gmail.com>.
Archie,
I like your idea of zero mods to JCHEVM. I will attempt to localize
all mods to Classlibrary's Kernel Classes. Maybe this set of modified
Kernel Classes could be used by any VM that runs GNU Classpath. I
will try some experiments with java class name space to see if we can
create wrappers that satisfy all the stakeholders.
- Weldon
On 2/10/06, Archie Cobbs <ar...@dellroad.org> wrote:
> Weldon Washburn wrote:
> > Because the wrapper is adding a layer of identically named methods and
> > thus potentially really confusing the name space, I renamed
> > java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray().
> > All the enties in _jc_ilib_table[ ] would also be "decorated" with
> > "wrapper".
>
> Is that really necessary? It seems to me that the existing JCHEVM
> native API can remain intact.
>
> There are great advantages in being able to run JCHEVM with both
> Classlib and Classpath at the same time for debugging purposes
> (not to mention Classlib on J9). The more combinations you can
> try, the easier it is to hone in on a bug's source. So I'd strongly
> prefer that the Java/VM API remain the same as much as possible.
> Certainly this can be done with the right "overlay" classes.
>
> Cheers,
> -Archie
>
> __________________________________________________________________________
> Archie Cobbs * CTO, Awarix * http://www.awarix.com
>
--
Weldon Washburn
Intel Middleware Products Division
Re: [jchevm] porting harmony classlib to JCHEVM
Posted by Archie Cobbs <ar...@dellroad.org>.
Weldon Washburn wrote:
> Do you know if anyone is working on a port of Harmony Classlib to
> JCHEVM? If false, I would like to start this port. I can't guarantee
> I have time to finish the port but intend to at least sketch out what
> needs to be done so that others can join the effort.
I don't know of anyone working on it yet. That would be great
to do some exploration.
Since JCHEVM already works with the VM interface defined by Classpath,
as much re-use of that API as possible makes a lot of sense. If we
can't import Classpath files directly (which itself is stupid and
highly ironic imho, but that's another discussion) then we can write
new files that provide the same API (doing that should not have any
copyright problems).
From my initial glances the Classpath API is often "lower level"
than the Classlib API, so all that would be needed in theory is to
fill the resulting gap with some Java code glue.
> I have started looking at JCHEVM to figure out how to glue the Harmony
> Classlibrary kernel classes (see
> …modules/kernel/src/main/java/java/lang/*.java) to the native entry
> points listed in jchevm/libjc/native_lib.c. The goal is to make only
> absolutely essential mods to JCHEVM code. Ideally, there would be
> zero changes to JCHEVM. All the "glue" would reside in JCHEVM's
> private copy of Classlib's kernel classes.
The "overlay" approach, which works well.
> Because the wrapper is adding a layer of identically named methods and
> thus potentially really confusing the name space, I renamed
> java_lang_VMClass_isArray() to java_lang_VMClass_wrapperIsArray().
> All the enties in _jc_ilib_table[ ] would also be "decorated" with
> "wrapper".
Is that really necessary? It seems to me that the existing JCHEVM
native API can remain intact.
There are great advantages in being able to run JCHEVM with both
Classlib and Classpath at the same time for debugging purposes
(not to mention Classlib on J9). The more combinations you can
try, the easier it is to hone in on a bug's source. So I'd strongly
prefer that the Java/VM API remain the same as much as possible.
Certainly this can be done with the right "overlay" classes.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com