harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Ellison <t.p.elli...@gmail.com>
Subject Re: [jchevm] porting harmony classlib to JCHEVM
Date Wed, 15 Feb 2006 11:52:06 GMT
Geir Magnusson Jr wrote:
> Archie Cobbs wrote:
>> 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.



Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.

View raw message