In message <94d710af0908112202x6eb5498dy9bd1dd84dbdde...@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.dea...@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.
