Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: neutral (nike.apache.org: 195.212.29.141 is neither permitted
 nor denied by domain of mark.hindess@googlemail.com)
Message-Id: <200908120654.n7C6sTjC024127@d06av03.portsmouth.uk.ibm.com>
In-reply-to: <94d710af0908112202x6eb5498dy9bd1dd84dbdde0b5@mail.gmail.com> 
References: <4A8179FC.9010409@googlemail.com>
 <94d710af0908112202x6eb5498dy9bd1dd84dbdde0b5@mail.gmail.com>
Comments: In-reply-to Sean Qiu <sean.xx.qiu@gmail.com>
   message dated "Wed, 12 Aug 2009 13:02:04 +0800."
From: Mark Hindess <mark.hindess@googlemail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm] Thread library function table added 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 12 Aug 2009 07:54:29 +0100


In message <94d710af0908112202x6eb5498dy9bd1dd84dbdde0b5@mail.gmail.com>,
Sean Qiu writes:
>
> +1 for both of your proposal, it sounds reasonable and cool.
> Thanks, Oli.

I am in favour of removing the option completely and removing the
classlib thread code.  Of course, this breaks the IBM VME so perhaps we
can leave it in place - but change the default? - until a new IBM VME is
available?

> One question here, what do you mean remove the code? svn del?
> What about we "svn move" it to some other place, such as
> 
> https://svn.apache.org/repos/asf/harmony/enhanced/legacy

Well, we already have:

  https://svn.apache.org/repos/asf/harmony/enhanced/classlib/archive

but I think "svn delete" is fine since you can always checkout earlier
revisions if you need to revisit the code.

Regards,
 Mark.

> 2009/8/11 Oliver Deakin <oliver.deakin@googlemail.com>:
> > Hi all,
> >
> > I have added an implementation of the thread library function table for
> > DRLVM which can be enabled by building with the "-Dhy.no.thr=true" flag
> > specified on the Ant command line. This means we no longer need to build th
> e
> > classlib thread library in the federated build, and we also no longer need
> > to copy the DRLVM hythr library into jre/bin (although I havn't changed the
> > build to not do the copy yet). I have temporarily set the hythr library
> > version to 0.2 so that the federated build can be run with and without the
> > hy.no.thr flag set.
> >
> > This opens a couple of questions for discussion:
> > 1) Shall we set the hy.no.thr option to true as default? I personally think
> > we should - the classlib hythr library is not used in the federated builds,
> > so there is no reason to continue building it.
> > 2) Shall we remove the thread library from classlib altogether? If
> > hy.no.thr=true becomes the default, I can see reasons for and against [1]
> > removing the source from classlib, but I think the reasons to remove the
> > code outweigh the reasons to keep it. My vote is to remove that source
> > module from classlib altogether.
> >
> > Ideas/comments?
> >
> > Regards,
> > Oliver
> >
> > [1] A few I can think of straight off:
> > For:
> > - Unused thread library code in classlib is unlikely to be maintained.
> > - Some classlib thread code is incorrect (x86_64 linux has some invalid
> > assembler code I believe).
> > - Shrinks the source tree footprint.
> > - All VMs will likely have their own implementation of this functionality
> > anyway.
> > Against:
> > - Raises the bar slightly for VM vendors wishing to use the Harmony class
> > libraries.