String concatenation tweaks

[Aleksey Shipilev]

On 06/04/2015 03:35 PM, Maurizio Cimadamore wrote:
> Well, yes - but adding a new indy is not something that comes for free.
> We are currently fighting to get specialization to work correctly with
> lambdas, and it turns out that having an indy, as Brian said, is like
> having an entirely new bytecode - so, for every new 'officially
> supported' bootstrap that we add, we will need to find ways to make that
> work with whatever new feature XYZ we could come up in the future.

Yes. This is why we better spend time figuring if the proposed indy
interface is enough/future-proof.


> So, my question remains: how much of that speedup can be obtained w/o
> indy? I think that's a fair question for the JEP you are filing.

And JEP addresses that in "Alternative" section, by talking why changing
the javac-generated bytecode sequence is not considered. The
considerations for the complexity of testing and/or JVM implementation
prevail: multiple bytecode sequences for String concat would mean the
JVM, the tools, everyone having another degree of freedom in their
testing matrices landing on their laps. Allowing complex static
translation schemes in javac would inevitably turn into a performance
nightmare, and I, for one, would not like to be responsible for it.

In other words, as far as the JVM and tools are concerned, the static
bytecode sequence emitted by javac is *as much* the interface as a
proposed indy sequence. The difference is whether you change it once
(into indy), or multiple times (as you get your static translation right
over the years).

Therefore, the answer to the question "how much performance can you gain
with doing that in plain javac" would not help you. The issue at hand is
*not* performance, but is enabling the performance work without
exploding the variety of bytecode shapes.

Anyhow, the experiment you want is not possible at this point, since
there is no alternative "patch" to be tried. Recognizing the
shortcomings of static javac-emitted concat sequences, I think the time
is best spent elsewhere, rather than trying to build a complicated piece
of code that would be thrown away for the reasons above.

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/20150604/f2364623/signature.asc>