String concatenation tweaks

[Aleksey Shipilev]

On 03/12/2015 11:34 AM, Aleksey Shipilev wrote:
> I am not really fond of doing the optimizations on javac level: asking
> users to recompile their programs for better performance and/or fixing
> the (probable) javac bugs is arguably against what users expect.

> But in this case, changing the bytecode shape before hitting the JIT
> compiler seems to be the sanest route. JIT compilers have to maintain
> more strong invariants than most users let on, see e.g.:
>   https://bugs.openjdk.java.net/browse/JDK-8043677

All right, let me propose a radical alternative here. Asking users to
recompile their Java code for performance once is probably okay, if we
describe the performance boosts. But asking for the second, third,
(N+1)-th time would probably make our lives harder -- people would
refuse to migrate, and we will be stuck supporting multiple possible
code shapes in VM.

Given we have arguments about the exact specifics how to generate string
concat on javac side, chances are we would not get it right from the
start; and we would need to make adjustments in future. This is
especially scary if we want to introduce special string builders that
would have to be leaked into bytecode ABIs.

If only there was a way to declare the intent in Java code, and then
delay the exact specifics how that intent is fulfilled (e.g. what code
is generated) until the JVM runs... wait, that's invokedynamic!

So, what if we make a radical ABI change once and for all: implement all
concatenations via (for example) the signature-polymorphic
java.lang.StringConcat.concat(Object... methods), and let JDK to figure
out how to do this exactly at runtime?

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/20150417/201cdb8e/signature.asc>