String concatenation tweaks

[Aleksey Shipilev]

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:
  http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/

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:
 http://cr.openjdk.java.net/~shade/scratch/string-concat-indy/jep.txt

Thanks,
-Aleksey

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20150529/76aac00e/signature.asc>