You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Oliver Deakin <ol...@googlemail.com> on 2009/08/11 16:02:36 UTC
[drlvm] Thread library function table added
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
Re: [drlvm] Thread library function table added
Posted by Oliver Deakin <ol...@googlemail.com>.
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 <ol...@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
Re: [drlvm] Thread library function table added
Posted by Pavel Pervov <pm...@gmail.com>.
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 <ol...@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
>
>
Re: [drlvm] Thread library function table added
Posted by Oliver Deakin <ol...@googlemail.com>.
Mark Hindess wrote:
> I think we should do this. However, this will "break" developers using
> the IBM VME. Perhaps we could do:
>
> Index: make/properties.xml
> ===================================================================
> --- make/properties.xml (revision 805151)
> +++ make/properties.xml (working copy)
> @@ -286,7 +286,10 @@
> <property name="exclude.module" value="nothing" />
>
> <!-- flags -->
> - <property name="hy.no.thr" value="false" />
> + <condition property="hy.no.thr" value="false">
> + <available file="${hy.hdk}/jdk/jre/bin/default/libj9vm23.so" />
> + </condition>
> + <property name="hy.no.thr" value="true" />
> <condition property="hy.skip.thr" value="true">
> <not>
> <equals arg1="${hy.no.thr}" arg2="false" />
>
> to mitigate this slightly?
>
It's not very pretty, but it would at least automate this step for the
current VME until it is updated. It would still be an issue if users
take a first time checkout of the class libraries, build them and then
overlay the IBM VME, as the j9vm23 library would not be present at build
time, but at least it would save us specifying the hy.no.thr flag for
subsequent builds. It also needs to look for j9vm23.dll on Windows,
having an <or> condition for either library should do the trick.
Regards,
Oliver
> Regards,
> Mark.
>
> In message <4A...@googlemail.com>, Oliver Deakin writes:
>
>> 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
>>>> <94...@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 <ol...@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 7415
>> 98.
>> 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
Re: [drlvm] Thread library function table added
Posted by Mark Hindess <ma...@googlemail.com>.
I think we should do this. However, this will "break" developers using
the IBM VME. Perhaps we could do:
Index: make/properties.xml
===================================================================
--- make/properties.xml (revision 805151)
+++ make/properties.xml (working copy)
@@ -286,7 +286,10 @@
<property name="exclude.module" value="nothing" />
<!-- flags -->
- <property name="hy.no.thr" value="false" />
+ <condition property="hy.no.thr" value="false">
+ <available file="${hy.hdk}/jdk/jre/bin/default/libj9vm23.so" />
+ </condition>
+ <property name="hy.no.thr" value="true" />
<condition property="hy.skip.thr" value="true">
<not>
<equals arg1="${hy.no.thr}" arg2="false" />
to mitigate this slightly?
Regards,
Mark.
In message <4A...@googlemail.com>, Oliver Deakin writes:
>
> 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
> >> <94...@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 <ol...@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 7415
> 98.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
Re: [drlvm] Thread library function table added
Posted by Oliver Deakin <ol...@googlemail.com>.
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
>> <94...@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 <ol...@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
Re: [drlvm] Thread library function table added
Posted by Oliver Deakin <ol...@googlemail.com>.
Mark Hindess wrote:
> In message <94...@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 <ol...@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
Re: [drlvm] Thread library function table added
Posted by Mark Hindess <ma...@googlemail.com>.
In message <94...@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?
> 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.
Regards,
Mark.
> 2009/8/11 Oliver Deakin <ol...@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.
Re: [drlvm] Thread library function table added
Posted by Sean Qiu <se...@gmail.com>.
+1 for both of your proposal, it sounds reasonable and cool.
Thanks, Oli.
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
Best Regards
Sean, Xiao Xia Qiu
2009/8/11 Oliver Deakin <ol...@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
>
>
Re: [drlvm] Thread library function table added
Posted by Xiao-Feng Li <xi...@gmail.com>.
Oliver, I support this idea.
Thanks,
xiaofeng
On Tue, Aug 11, 2009 at 10:02 PM, Oliver
Deakin<ol...@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