harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Weldon Washburn <weldon...@gmail.com>
Subject Re: [jchevm] porting harmony classlib to JCHEVM
Date Wed, 15 Feb 2006 19:15:25 GMT
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.p.ellison@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

Mime
View raw message