harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [drlvm] Thread library function table added
Date Wed, 12 Aug 2009 06:54:29 GMT

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.



Mime
View raw message