Review: Indify String Concat JEP

[Aleksey Shipilev]

Hi Alan,

Thanks for taking a look!

On 09/21/2015 02:24 PM, Alan Bateman wrote:
> On 18/09/2015 16:17, Aleksey Shipilev wrote:
>> Please review the submitted "Indify String Concat" JEP. It seems
>> complete to me: with working implementation, testing, and general
>> understanding of an issue. Start here:
>>    https://bugs.openjdk.java.net/browse/JDK-8085796

> On startup overhead then it might be amortized by the initialization of
> the module system as you suggest. It might be something else. We don't
> want to discourage use of lambda expressions or method reference so the
> first use of LF or whatever the initialization cost is will need to be
> worked on anyway.

I finally had time to follow up why default jdk9 regresses on startup
time, and this opened the way to properly re-estimate the startup costs
for Indify String Concat. It indeed points fingers at j.l.invoke, as we
figured a few months ago. See the "Startup considerations" section in
the notes:
  http://cr.openjdk.java.net/~shade/8085796/notes.txt

It might very well mean this is an inherent tax on all j.l.invoke users.
The good news is that this tax is not cumulative, and
only the first user pays for it. See:
  https://bugs.openjdk.java.net/browse/JDK-8086045


> I see the proposal is to exempt java.base. It probably could be finer
> grained than all of java.base but tricky to determine that subset. Even
> if all of java.base is exempt then I think there are initialization
> issues that need to be looked at. 

Our very first prototype was to hack java.lang.invoke to use explicit
StringBuilders instead of implicit concat to avoid the circularity and
see how hard it would be to provide a fine-grained exception rules. I
gave up trying to do this, because it metastasizes very quickly all
around java.base.

Therefore, I thought exempting java.base completely is a sane option.
It's just more hassle-free to let java.lang.invoke use anything
reachable in java.base.


> One other thing is that JEP 261 proposes the -Xoverride option (maybe it
> might be renamed to -Xpatch) for patching/override classes in java.base.
> Anyone using that to override classes used early in the startup would
> need to be careful to use the right javac option.

Okay, this sounds as the argument for -XstringConcat to exist in javac
flags :) Bootclasspathing an alien class into a cohesive module sounds
dangerous anyhow, and the sane thing we can do is to fail predictably.
The init circularities now end up with StackOverflowErrors.


> One other other on exemptions is that it might need to be javac too, at
> least for the JDK build where the newly built compiler runs with the
> boot JDK to compile everything else. I can't quite tell from a first
> read if the proposal is that javac emit indy by default, if not then
> this may be a non-issue.

In current implementation, javac emits "indyStatic" flavor by default,
and -XstringConcat can be used to switch the flavor back. I see little
value to make this future opt-in.

Yes, jdk.compiler also builds with "inline" flavor, that is, the same
current inline StringBuilder::append chains. This is a sample diff:
 http://cr.openjdk.java.net/~shade/8085796/root.patch

Thanks,
-Aleksey