This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Patch: RFC: String sharing heuristic


I'm a bit concerned about the number of initial tests we
perform in the substring operation before we do any real
work.  I think there's something to be said for keeping the
number of tests here down.  But I'm not sure what the best
way to do that is.  Perhaps a combined test like

newCount-8 < (count >> 2) ?

(Does Tom's original test have overflow issues?)

Hans

> -----Original Message-----
> From: java-patches-owner@gcc.gnu.org 
> [mailto:java-patches-owner@gcc.gnu.org] On Behalf Of David Daney
> Sent: Thursday, May 12, 2005 12:42 PM
> To: Bryce McKinlay
> Cc: tromey@redhat.com; Java Patch List
> Subject: Re: Patch: RFC: String sharing heuristic
> 
> 
> Bryce McKinlay wrote:
> > I think this patch makes sense. In fact I suspect that its 
> very common
> > for the original string to be thrown out when substring() 
> is used, so 
> > perhaps we could make the threshold even more conservative, eg (2 * 
> > newCount) ?
> 
> How about a non-linear huristic?
> 
> Under 100 chars always share, More than 100 do something else.
> 
> David Daney
> 
> 
> > 
> > 
> > Tom Tromey wrote:
> > 
> >> Please comment on this.
> >>
> >> Christopher Lansdown  showed me  an example program  that 
> >> unexpectedly used  a lot of  memory (as  compared to  running on  
> >> jamvm).  Analysis showed that  he was  using substring(), 
> which  was 
> >> keeping  the entire contents  of  his 300M  log  file live  --  
> >> whereas  the heuristic  in Classpath's substring() avoided this.
> >>
> >> This is obviously an extreme example.  I'm inclined to put 
> this patch 
> >> in, but I was hoping someone out there had a better 
> argument for or 
> >> against than "this one program benefited".  Obviously any 
> heuristic 
> >> here can't please everyone...
> >>
> >> Tom
> >>
> >> Index: ChangeLog
> >> from  Tom Tromey  <tromey@redhat.com>
> >>
> >>     * java/lang/natString.cc (substring): Changed sharing 
> heuristic.
> >>
> >> Index: java/lang/natString.cc 
> >> ===================================================================
> >> RCS file: /cvs/gcc/gcc/libjava/java/lang/natString.cc,v
> >> retrieving revision 1.37
> >> diff -u -r1.37 natString.cc
> >> --- java/lang/natString.cc 22 Apr 2005 19:02:41 -0000 1.37
> >> +++ java/lang/natString.cc 11 May 2005 21:00:41 -0000
> >> @@ -1,6 +1,6 @@
> >> // natString.cc - Implementation of java.lang.String 
> native methods.
> >>
> >> -/* Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004  Free
> >> Software Foundation
> >> +/* Copyright (C) 1998, 1999, 2000, 2001, 2002, 2003, 2004, 2005  
> >> +Free
> >> Software Foundation
> >>
> >>    This file is part of libgcj.
> >>
> >> @@ -829,7 +829,7 @@
> >>   if (beginIndex == 0 && endIndex == count)
> >>     return this;
> >>   jint newCount = endIndex - beginIndex;
> >> -  if (newCount <= 8)  // Optimization, mainly for GC.
> >> +  if (newCount <= 8  || (4 * newCount) < count)    // 
> Optimization, 
> >> mainly for GC.
> >>     return JvNewString(JvGetStringChars(this) + 
> beginIndex, newCount);
> >>   jstring s = new String();
> >>   s->data = data;
> >>  
> >>
> > 
> 
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]