JEP 280 (Indify String Concat) integration

[Paul Sandoz]

Looks a fine approach to me.

Getting code in earlier and tested, even initially under the less optimal strategy, is good in terms of exposure.

Paul.

> On 22 Jan 2016, at 10:31, Aleksey Shipilev <aleksey.shipilev at oracle.com> wrote:
> 
> Hi,
> 
> I think it is time to integrate JEP 280 ("Indify String Concat") into JDK 9:
> http://openjdk.java.net/jeps/280
> 
> The JEP is Targeted, the CCC is approved, the code reviews and
> pre-integration checks come clean. In theory, we would like to integrate
> with some "optimal" concat strategy switched by default, but we have to
> wait for some Hotspot compiler changes to settle before we can make that
> call. (Notably, https://bugs.openjdk.java.net/browse/JDK-8136469).
> 
> So, I would like to proceed in two parts:
> 
> Part 1: Integrate all code changes, but keep the concatenation strategy
> to be the same "naive" StringBuilder.append chains. In other words, we
> are emitting string concat indy, but always link in the naive
> StringBuilder.append code.
> 
> Part 2: (After HS changes settle in) Re-run performance tests, and
> switch to a more optimal concatenation strategy. This amounts to
> one-liner change in a default value for Java property.
> 
> Thoughts? I would like relevant Project Leads / Reviewers (langtools and
> jdk) to OKay the integration.
> 
> FTR, the webrevs:
>  http://cr.openjdk.java.net/~shade/8085796/webrev.root.00/
>  http://cr.openjdk.java.net/~shade/8085796/webrev.langtools.05/
>  http://cr.openjdk.java.net/~shade/8085796/webrev.jdk.08/
> 
> Thanks,
> -Aleksey
>