Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of xiaofeng.li@gmail.com
 designates 74.125.92.148 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=SKRzIowZu41aNlRQPEi2mHO7IvuEjeMW6ChmNH3O/8ZUfq1VGJy4+w1NipCNH0Srqn
         TO5+CJgCccV1lcRVinuopzYVdbuIUOn2h50h2UNOHmxpUqapKA7pUI19Ji6n+72aPfTV
         GjkBCjOEwkGgwfes5o9HHWM4Ih8h4w84MbO40=
MIME-Version: 1.0
In-Reply-To: <4A8179FC.9010409@googlemail.com>
References: <4A8179FC.9010409@googlemail.com>
Date: Wed, 12 Aug 2009 08:24:01 +0800
Message-ID: <9623c9a50908111724v7c5c4f08j2bfc1f97a65be4af@mail.gmail.com>
Subject: Re: [drlvm] Thread library function table added
From: Xiao-Feng Li <xiaofeng.li@gmail.com>
To: dev@harmony.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Oliver, I support this idea.

Thanks,
xiaofeng

On Tue, Aug 11, 2009 at 10:02 PM, Oliver
Deakin<oliver.deakin@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