String concatenation tweaks

Peter Levart peter.levart at
Sun May 31 21:06:18 UTC 2015

On 05/31/2015 10:58 PM, Peter Levart wrote:
> On 05/28/2015 11:22 PM, Aleksey Shipilev wrote:
>> 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.
>> Merged:
>> 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:
>> Thanks,
>> -Aleksey
> Hi,
> This is a noble goal. I will just warn you about the possible 
> initialization problems. String concatenation is a very rudimentary 
> operation and might be used very early in the startup of the JVM. If 
> it is used before the system class loader is initialized (before the 
> main method is executed), you will be faced with the following issue 
> at least:
> we might need to fix these early java.lang.invoke initialization 
> problems 1st.

Not to mention that java.lang.invoke infrastructure (at least the part 
that is used to support invokedynamic etc.) should then *not* use string 

> Regards, Peter

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

More information about the compiler-dev mailing list