String concatenation tweaks

Aleksey Shipilev aleksey.shipilev at oracle.com
Fri Jun 12 16:56:34 UTC 2015


Thanks for the discussion, guys. I added your concerns and answers to
the JEP draft:
  https://bugs.openjdk.java.net/browse/JDK-8085796

My only concern is this:

On 06/06/2015 11:37 PM, Maurizio Cimadamore wrote:
> On 06/06/15 15:41, Remi Forax wrote:
>> Now, I think that the String concatenation based on invokedynamic
>> should be integrated in 9, behind a -XD option of javac at first,
>> because it's a good simple example that exercise method handle
>> combiners with multiple shapes and see if the startup problem can be
>> solved for that case. 
> This seems like a very sensible plan. At the very least we will have a
> chance to test the bits and have a better grip on what real world impact
> is gonna look like.

As far as I can see, there is little sense to integrate the feature into
the next major release, and not turn it on by default. What would be the
point? You can change the bytecode shape that drastically only in a
major release. Which means if we commit it in disabled form for JDK 9,
we can only turn in back on in JDK 10.

The realistic "dragging our feet" scenario I see with this approach is
that we commit the feature disabled under the flag, keep it lingering
there, with no one caring enough to use this in production before it is
declared "official", fast-forward to Java (N+1) timeframe, have the same
discussion about the drawbacks of unleashing the feature into the world
by default, N++, rinse and repeat.

I think a sensible plan would be to integrate to 9 with the bytecode
translation strategy *exactly* dubbing what's done in javac right now
(INNER), forcing everyone to adjust to new bytecode shape early, then
improve translation strategies in the (minor) update releases.

What am I missing here? Are we concerned the javac-bytecode protocol
would need more touchups, after we figure it out in the course of the
current work?

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/09b1136c/signature.asc>


More information about the compiler-dev mailing list