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 <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) > IBM Java technology centre, UK. > -- Weldon Washburn Intel Middleware Products Division
