classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Contributions of work on Jikes RVM with GNU Classpath


From: John Leuner
Subject: Re: Contributions of work on Jikes RVM with GNU Classpath
Date: 05 Dec 2002 16:32:37 +0000

For patch 728 (quicksort), do you have a testcase that demonstrates
failure in the existing code?

Does this patch actually change the end result, or is it just meant to
be a performance enhancement?

Thanks
John Leuner


Index: java/util/Arrays.java
===================================================================
RCS file: /cvsroot/classpath/classpath/java/util/Arrays.java,v
retrieving revision 1.18
diff -u -r1.18 Arrays.java
--- java/util/Arrays.java       6 May 2002 16:19:20 -0000       1.18
+++ java/util/Arrays.java       25 Nov 2002 20:58:06 -0000
@@ -1929,7 +1929,7 @@
 
     // Pull the median element out of the fray, and use it as a pivot.
     swap(from, mid, array);
-    a = b = from;
+    a = b = from + 1;
     c = d = from + count - 1;
 
     // Repeatedly move b and c to each other, swapping elements so
@@ -1970,7 +1970,7 @@
     vecswap(from, b - span, span, array);
 
     span = Math.min(d - c, hi - d - 1);
-    vecswap(b, hi - span, span, array);
+    vecswap(c, hi - span, span, array);
 
     span = b - a;
     if (span > 1)


>  I have broken the changes we made down into small, related sets of diffs
> and have submitted them using the `submit patch' feature on the classpath
> web site.  they are patches 716-728.
> 
>       -- Julian
> 
> 
> 
>                                                                               
>                         
>                       Brian Jones                                             
>                         
>                       <address@hidden>            To:       Mark Wielaard 
> <address@hidden>               
>                       Sent by:                 cc:       Julian 
> Dolby/Watson/address@hidden,               
>                       address@hidden               address@hidden,            
>                         
>                                                 address@hidden, Michael  
>                                                 Hind/Watson/address@hidden, 
> address@hidden              
>                       11/21/02 04:24 PM        Subject:  Re: Contributions of 
> work on Jikes RVM with  
>                                                 GNU Classpath                 
>                         
>                                                                               
>                         
>                                                                               
>                         
>                                                                               
>                         
> 
> 
> 
> Mark Wielaard <address@hidden> writes:
> 
> > >  We would be happy to contribute our changes in any manner people at
> > > GNU Classpath find convenient.  We can send you diffs in any format or
> > > simply a tarball of the GNU Classpath tree we have here.  Please let
> > > me know what you would find most useful.
> >
> > It is probably a good idea to make a new release of GNU Classpath first
> > (say in the next two weeks). So that we have a clear point from which to
> > start merging in the changes. The last GNU Classpath release was a
> > couple of months ago and a lot of changes have been made. I will propose
> > a release schedule on the GNU Classpath list later today since I wanted
> > to have a new release anyway soon. But it depends a bit on the number of
> > changes that you have, if there are not that many then maybe waiting a
> > little longer with a new release might be a better option.
> 
> I would prefer to integrate the changes from a recent CVS diff to add
> this functionality in before the next release.  The changes in the VM
> layer should be integrated as quickly as possible.  I am also much
> happier about big diffs when there are Mauve tests to prove them out,
> but this is more of a strong suggestion than a requirement.  I think
> it works out best to make the diffs small, by package for example, and
> include appropriate ChangeLog entries.
> 
> It's much easier to see that a two-line change makes sense than to
> review a massive diff for example.
> 
> > The best way to do the actual merge/patches is by trying to identify
> > independent changes and post them on the classpath mailinglist so people
> > can discuss them. Just sending a big tarball or one gaint patch/diff
> > makes it hard to analyse what changed and for what reason. If you send
> > patches to the mailinglist please try to create diffs against the
> > current CVS tree and use unidiffs (cvs diff -u). If splitting up the
> > changes is not possible you can always make a unidiff of the changes and
> > add it to the Patch Manager http://savannah.gnu.org/patch/?group_id=85
> > but then it might take a (long) while before the patches will actually
> > be merged.
> 
> I prefer diffs/patches always make it into the patch manager just so
> they don't get lost.  If the big diff is split up then people can take
> ownership of integrating each as needed.  Copying the mailing list is
> okay too... I think we have a 300K mail size limit though thus smaller
> is always better.
> 
> > Brian Jones can also give one of you CVS write access to the GNU
> > Classpath tree if you want.
> 
> There are some legalities involved I don't understand yet.  I would
> like to do this, but I don't know that I can or that IBM desires it.
> 
> > >  Thanks to John Leuner for getting the whole Jikes RVM on GNU
> > > Classpath work started and doing the initial port.
> >
> > Yes. Thanks a lot John!
> 
> Thanks John and JRVM team!
> --
> Brian Jones <address@hidden>
> http://www.haphazard.org/~cbj/
> 
> 
> 
> 
> 
> _______________________________________________
> Classpath mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/classpath

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]