I believe a long time ago it used to work this way; there was a private "handoff" constructor in String that StringBuffer would use. Probably got changed when we added StringBuilder?
On Nov 6, 2013, at 10:54 PM, Robert Stupp wrote: > Hi, > > I was wondering why the mostly allocated class in nearly all applications is > char[]. A deeper inspection showed that a lot of these char[] allocations are > "caused" by the code from java.lang.StringBuilder.toString(), which created a > copy of its internal char array. Most StringBuilder instances are no longer > used after the call to StringBuilder.toString(). Many of these instances have > been created by javac caused by "plain" string concatenation in source code. > > Wouldn't it worth to try whether passing the (Abstract)StringBuilder's > value+count values to String results in less temporary object creations and > therefore reduce pressure on new generation (and reduce GC effort)? My idea > is to add a field 'shared' to AbstractStringBuilder, which is set when > StringBuilder.toString() is called. If the StringBuilder is really modified > after calling toString(), the StringBuilder creates a new copy of the value > array and resets the 'shared' field. Since the value array might be longer > than the current count, String class would need a "re-invention" of the count > field. > > Another think I noticed is that the StringBuilder instances transiently > created by javac seem to use the default constructor. But a huge amount of > string concatenations in Java code result in (much) longer Strings, which > means that each append creates a new, larger copy of the value array in > AbstractStringBuilder. Is it possible to add some "guessing" for the initial > capacity - this would eliminate a lot of temporary objects and reduce GC > effort. Is it worth to check this out? Are the two places in > com.sun.tools.javac.jvm.Gen#visitAssignop/visitBinary the only places where > these StringBuilder instances are created? > > - > Robert >
