Patch: RFC: String sharing heuristic

[Tom Tromey]

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;