String concatenation tweaks

[Aleksey Shipilev]

First things first, I added more discussion into the JEP draft:
 https://bugs.openjdk.java.net/browse/JDK-8085796


On 06/04/2015 08:50 PM, Maurizio Cimadamore wrote:
> On 04/06/15 17:23, Aleksey Shipilev wrote:
>> While it maybe an interesting experiment to try, the performance
>> engineering experience tells me to focus on the parts that are relevant,
>> rather than doing every experiment you can come up with, otherwise you
>> will never ever un-bury yourself from the performance work:)

> I don't think this is *any* experiment you can come up with - it's the
> very foundation for all the JEP work. For the JEP to be viable you need
> to prove that whatever technique you come up with, it would be almost in
> the same ballpark as the one implemented in javac. 

If you want to assess the technique itself, you have to compare the
similar concat approaches used by javac and by indy-based translation
strategy. It would be dumb to compare a heavily-optimized javac
translation vs. a dumb indy-based translation.

This is why we have INNER, it is the (almost) direct rewrite of the code
emitted by vanilla javac now, to the runtime. This strategy is actually
used to prove the move from compile time to runtime does not experience
the throughput hits. *That's* the foundational performance data, already
available.


> If the numbers are the same, then it's mostly an argument of whether
> we want to open up the machinery vs. keeping it buried in javac (and
> the future maintenance cost for any BSM added). But what if the
> numbers are not the same?

But they are the same already! INNER performs the same as vanilla javac
(BASELINE) is performing. This means the new infrastructure is not
getting in the way, when our translation strategy emits the plain
bytecode. Heck, both BASELINE and INNER are recognized by
OptimizeStringConcat and are optimized to death.

That's what I am trying to tell here: it _is_ the question about the
machinery at this point. All other strategies are motivational examples
how this can be used to improve the translation strategy without
involving javac.


> Put in other words, if the natively written javac impl was 10x faster
> with no startup cost (I'm obviously making things up), wouldn't that
> mean the very death of this JEP?

No, it wouldn't. Because really, whatever bytecode you can emit in
javac, the same bytecode can be emitted through the indy translation
strategy. (The reverse is not true -- JDK-internal StringConcatFactory
may use private APIs! -- which makes javac more limiting for this task).

If you discover a bytecode sequence that is 10x faster than proposed
variants in indy translation strategies, you move it in as additional
strategy, and that's it (plus the beauty that you can discover such a
bytecode sequence much later).

This is why we would certainly like to see Louis' patch, to see if we
can/need to move it in under indy translation strategy, and if/what we
should adjust at the indy interface.

The only plausible concern at this point is startup time, but you can
see that even without going with additional javac experiments. And,
those costs seem to be related to the initialization of indy
infrastructure -- some project would have to suck up those costs,
whether it's String Concat, Jigsaw, on any Valhalla-related project.

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/20150605/d6c6cd0d/signature.asc>