harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: [drlvm] Thread library function table added
Date Tue, 18 Aug 2009 11:31:41 GMT

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 <4A8A7B91.6090206@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 
> >> <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 7415
> 98. 
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 



Mime
View raw message