Oliver, I support this idea. Thanks, xiaofeng
On Tue, Aug 11, 2009 at 10:02 PM, Oliver Deakin<oliver.dea...@googlemail.com> wrote: > 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 the > 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. > > > -- > Oliver Deakin > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire > PO6 3AU > > -- http://people.apache.org/~xli