harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oliver Deakin <oliver.dea...@googlemail.com>
Subject Re: [drlvm] Thread library function table added
Date Fri, 14 Aug 2009 08:47:32 GMT
Mark Hindess wrote:
> 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?
>   
Yes, I think we should switch the default to hy.no.thr=true for a 
transition period. There is no harm in keeping the classlib thread code 
present for a while, but I think the eventual goal should be to delete 
it from the repo.

>   
>> 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.
>   

Agreed.

Regards,
Oliver

> 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.
>>>       
>
>
>
>   

-- 
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


Mime
View raw message