StringBuilder buffer allocation support in compiler

John Rose john.r.rose at
Mon Jun 9 22:57:06 UTC 2014

On Jun 9, 2014, at 3:39 PM, Fredrik Öhrström <oehrstroem at> wrote:

> I do not know how Hotspot optimizes string concatenations, but JRockit did some fun things as well, like replacing StringBuilder (at runtime) with an internal JRockit specific StringMaker, that merely stored references to the constant strings in an array.

But could JRockit EA-away the array, unroll the loops, and turn everything into custom code?

Come to think of it, JRockit could.  Nice trick.

Hmm, I wonder if we have any other types that set up with cumulative method-call chains but need to boil down to custom code.  There was this thing called "Streams", wasn't there?  :-)

My bottom line: The JVM needs to get a better handle on these builder patterns.

> Thus the .append(x) did very little work, all the concatenation work then happened in toString() where it first scanned the appended strings length and could calculate the final length of the concatenated string. Thus only a single allocation was necessary and there was no superfluous copying.

On Jun 6, 2014, at 9:25 AM, Robert Field <Robert.Field at> wrote:

> Notes from the peanut gallery:  If this is an important case to optimize, then a set of constructors which take N Strings seems it would give you much more.

For built-in stuff like string formatting expressions, lambda expressions, and (eventually) object constructor expressions ("enhanced literals"), a very good trick, IMO, is coding the form of the result into an invokedynamic, and letting a system metafactory figure out the optimal implementation.  As you know, Robert, with a MF you can pretend you have an infinite family of object constructors, each with exactly the right signature required at the point of use.  This would work fine for string formatting expressions.  It would be about as compact (or slightly more so) than the current StringBuilder code shapes, but would allow the JVM the option to generate exactly customized code for each combination of constant and variable formatting components.

— John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the compiler-dev mailing list