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 Wed, 12 Aug 2009 11:48:12 GMT
Thanks Pavel - the code is now committed and can be built by specifying 
-Dhy.no.thr=true on the ant command line.

Regards,
Oliver

Pavel Pervov wrote:
> Oliver.
>
> This is great progress with threading library. Once the table
> implementation is committed, we can move threading code inside harmony
> vm module from the separate dynamic library, which will certainly give
> us additional performance.
>
> Pavel.
>
> 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
>> 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
>>
>>
>>     
>
>   

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