Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (nike.apache.org: domain of oliver.deakin@googlemail.com
 designates 74.125.78.148 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=K5pvHSvvdMw75ItTvoBwqCU2F0+Ax3SIU9wMLLI9Qf/9HjThUval6OnbvD3ctdiW53
         QNhGbxGX+onVCjTn/8kmqp1YmkG1l6Jus6fAjfSAve60d3L9EOelM7iVjUvMfouMqQKz
         hy2YrvjdRYU5ayh67vSkJkf86j0UmfpzxcUOc=
Message-ID: <4A82ABFC.6020909@googlemail.com>
Date: Wed, 12 Aug 2009 12:48:12 +0100
From: Oliver Deakin <oliver.deakin@googlemail.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [drlvm] Thread library function table added
References: <4A8179FC.9010409@googlemail.com>
 <e0f125db0908120445g65853f59g2818d7fd0b6d47d9@mail.gmail.com>
In-Reply-To: <e0f125db0908120445g65853f59g2818d7fd0b6d47d9@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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