Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 60700 invoked from network); 15 Feb 2006 11:52:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Feb 2006 11:52:35 -0000 Received: (qmail 10237 invoked by uid 500); 15 Feb 2006 11:52:31 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 10036 invoked by uid 500); 15 Feb 2006 11:52:30 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 10025 invoked by uid 99); 15 Feb 2006 11:52:30 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2006 03:52:30 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=RCVD_IN_SORBS_WEB,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: 217.158.94.220 is neither permitted nor denied by domain of t.p.ellison@gmail.com) Received: from [217.158.94.220] (HELO cirrus.purplecloud.com) (217.158.94.220) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Feb 2006 03:52:28 -0800 Received: (qmail 81829 invoked from network); 15 Feb 2006 11:52:07 +0000 Received: from blueice4n2.uk.ibm.com (HELO ?9.20.183.163?) (195.212.29.92) by smtp.purplecloud.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 15 Feb 2006 11:52:07 +0000 Message-ID: <43F315E6.6000202@gmail.com> Date: Wed, 15 Feb 2006 11:52:06 +0000 From: Tim Ellison User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: harmony-dev@incubator.apache.org Subject: Re: [jchevm] porting harmony classlib to JCHEVM References: <4dd1f3f00602101153w7ea069bidae77d152ff4f43f@mail.gmail.com> <43ED1A79.7020704@dellroad.org> <4dd1f3f00602110726h9ffc0d7x8224f75772eeb329@mail.gmail.com> <43EE512F.9030101@pobox.com> <43EE59C7.4030300@dellroad.org> <43EF5E39.9080208@pobox.com> In-Reply-To: <43EF5E39.9080208@pobox.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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. Regards, Tim -- Tim Ellison (t.p.ellison@gmail.com) IBM Java technology centre, UK.