String concatenation tweaks

Aleksey Shipilev aleksey.shipilev at
Thu May 28 21:22:50 UTC 2015

On 05/26/2015 04:31 PM, Remi Forax wrote:
> On 05/25/2015 09:01 PM, Aleksey Shipilev wrote:
>> The performance is interesting. It seems to break OptimizeStringConcat,
>> and so it's a performance win only on non-optimized chains, like
>> string_string_long. The allocation pressure is slightly higher as well,
>> seems to be because int[] from the collector is not scalarized.
> I wonder if the two things are not related, fail to unroll -> creation
> of int[] -> non constant value for the StringBuilder constructor ->
> break of OptimizeStringConcat optimization.


It seems OptimizeStringConcat expects a particular C2 IR graph shape,
and it might be hard to reproduce on MHs. Anyhow, your new FULL_MH now
performs the same as INNER_SIZED when OptimizeStringConcat fails, both
throughput-performance- and allocation-wise on small count of int arguments.

Please note I added a simple regression test, and munged the code to
make it pass. StringBuilder::append overloads are not present for every
type, and also we need to bypass StringBuffers/CharSequences.

It would seem INNER_SIZED is a good strategy to default to, and
subsequent JDK improvements can be done after the infrastructure lands.
The whole point for this change is to open the door for these
improvements. Meanwhile, I put together a very rough JEP draft here, and
I would appreciate comments and corrections:


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the compiler-dev mailing list