<div dir="ltr">I would be thrilled to see that level of magic, though that's probably beyond my personal abilities to implement or contribute as a patch.<br></div><br><div class="gmail_quote">On Fri, Apr 17, 2015 at 10:05 AM Remi Forax <<a href="mailto:forax@univ-mlv.fr">forax@univ-mlv.fr</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
On 04/17/2015 06:51 PM, Aleksey Shipilev wrote:<br>
> On 03/12/2015 11:34 AM, Aleksey Shipilev wrote:<br>
>> I am not really fond of doing the optimizations on javac level: asking<br>
>> users to recompile their programs for better performance and/or fixing<br>
>> the (probable) javac bugs is arguably against what users expect.<br>
>> But in this case, changing the bytecode shape before hitting the JIT<br>
>> compiler seems to be the sanest route. JIT compilers have to maintain<br>
>> more strong invariants than most users let on, see e.g.:<br>
>>    <a href="https://bugs.openjdk.java.net/browse/JDK-8043677" target="_blank">https://bugs.openjdk.java.net/browse/JDK-8043677</a><br>
> All right, let me propose a radical alternative here. Asking users to<br>
> recompile their Java code for performance once is probably okay, if we<br>
> describe the performance boosts. But asking for the second, third,<br>
> (N+1)-th time would probably make our lives harder -- people would<br>
> refuse to migrate, and we will be stuck supporting multiple possible<br>
> code shapes in VM.<br>
><br>
> Given we have arguments about the exact specifics how to generate string<br>
> concat on javac side, chances are we would not get it right from the<br>
> start; and we would need to make adjustments in future. This is<br>
> especially scary if we want to introduce special string builders that<br>
> would have to be leaked into bytecode ABIs.<br>
><br>
> If only there was a way to declare the intent in Java code, and then<br>
> delay the exact specifics how that intent is fulfilled (e.g. what code<br>
> is generated) until the JVM runs... wait, that's invokedynamic!<br>
><br>
> So, what if we make a radical ABI change once and for all: implement all<br>
> concatenations via (for example) the signature-polymorphic<br>
> java.lang.StringConcat.concat(Object... methods), and let JDK to figure<br>
> out how to do this exactly at runtime?<br>
<br>
yes :)<br>
<br>
you don't need a signature polymorphic method, indy is enough,<br>
<br>
Object a = ...<br>
int b = ..<br>
a + " foo " + b<br>
<br>
can be compiled to:<br>
   aload 0  // a<br>
   iload 1  // b<br>
   invokedynamic (Ljava/lang/Object;I)Ljava/lang/String;<br>
     java.lang.invoke.StringConcat [0, "foo", 1]<br>
<br>
note that in that case, Java can also support the interpolation syntax:<br>
   "$a foo $b"<br>
because the translation is exactly the same :)<br>
<br>
><br>
> Thanks,<br>
> -Aleksey.<br>
><br>
<br>
cheers,<br>
Rémi<br>
<br>
</blockquote></div>