This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
RE: Patch: RFC: String sharing heuristic
- From: "Boehm, Hans" <hans dot boehm at hp dot com>
- To: "David Daney" <ddaney at avtrex dot com>,"Bryce McKinlay" <mckinlay at redhat dot com>
- Cc: <tromey at redhat dot com>, "Java Patch List" <java-patches at gcc dot gnu dot org>
- Date: Thu, 12 May 2005 13:07:18 -0700
- Subject: 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;
> >>
> >>
> >
>
>