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 Tue, 18 Aug 2009 09:59:45 GMT
Carrying on from this discussion, I'd like to make hy.no.thr=true the 
default setting and stop building the classlib thread library in the 
federated build.

Please let me know if there are any objections/comments on this, 
otherwise I will make the change after M11 is published.

Regards,
Oliver

Oliver Deakin wrote:
> 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