String concatenation tweaks

[Aleksey Shipilev]

On 06/08/2015 09:31 AM, Peter Levart wrote:
> I played with this a bit and it's cool. I created a full-MH strategy
> called EXACT which always calculates upfront exactly what the resulting
> string length will be so that it never reallocates the building buffer.
> It doesn't use StringBuilder at all, but directly fills-in a char[]
> which it then constructs resulting String with without copying the
> array. 

> Here's the implementation:
>  http://cr.openjdk.java.net/~plevart/misc/StringConcatenation/webrev.01/

Sweeeeet! I merged it to my patchset, thanks!

The performance is indeed very promising:
  http://cr.openjdk.java.net/~shade/8085796/notes.txt

I have one doubt though. With the advance of Compact Strings (JEP-254),
we would need to adjust EXACT strategy, since it would go through the
non-optimal String repacking codepath. JEP-254 adjusts StringBuilder and
OptoStringConcat for new String shapes. Therefore, I think the default
translation strategy for JDK 9 (if we target it) should still be
INNER_*. EXACT is a very compelling argument for invokedynamic-based
String concat machinery.


> It doesn't beat INNER strategies for small sizes, but does quite well
> with bigger sizes. 

Looking briefly at "-prof perfasm" output for EXACT strategy and
comparing it against INNER/OptimizeStringConcat, it would seem
String.getChars/System.arraycopy is not optimized by this fix:
 https://bugs.openjdk.java.net/browse/JDK-6912521

E.g. this is one hotspot in EXACT strategy:

;*invokestatic arraycopy
; - java.lang.String::getChars at 12 (line 788)
; java.lang.StringConcatHelper::prepend at 10 (line 87)
  0.93%    1.11%    0x00007fe0442b6a60: rep rex.W stos %al,%es:(%rdi)
 17.21%   18.27%    0x00007fe0442b6a63: mov    %r11d,%ebp


> It is better than Remi's FULL_MH which is also
> "full-mh". I think it is a good candidate for optimization, since it
> seems it has a constant overhead which is not caused by sub-optimal
> algorithm. Perhaps by encoding the algorithm in a spinned inner class?

Maybe. But I would think Hotspot compiler guys would like to optimize
the MH-based version first. Also, quirks like the one explained above
should be worked out before going crazy with more inner classes :)

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/20150612/bd0f5abd/signature.asc>