Yes, it's time to integrate that code, thumb up ! BTW, once the second part will be done, varargs calls should be the next target, see https://bugs.openjdk.java.net/browse/JDK-8013269.
Rémi ----- Mail original ----- > De: "Paul Sandoz" <[email protected]> > Cc: [email protected], "Java Core Libs" > <[email protected]> > Envoyé: Vendredi 22 Janvier 2016 10:46:14 > Objet: Re: JEP 280 (Indify String Concat) integration > > 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 <[email protected]> > > 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 > > > >
