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 <[EMAIL PROTECTED]> 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
