RFR: 8160302: Reduce number of lambdas created when loading java.util.regex.Pattern

[Claes Redestad]

Hi Martin!

On 2017-02-01 20:48, Martin Buchholz wrote:
> I agree with the startup improvement goal.
> The need to do:
>
> + case "ALPHA": return ALPHABETIC();
>
> is pretty horrible (but we do worse in the name of performance).  We'd
> like to be able to simply do:
> return Character::isAlphabetic;
> but probably we're stymied by hotspot's eagerness being per-method, not
> per-statement.

I'm not sure I agree it's *that* horrible, but maybe I've grown
accustomed to somewhat horrible code... :-)

And no, while hotspot might the bytecode for a method eagerly, I'm
pretty sure the bootstrap method, which does the actual lambda
initialization and replace the instruction at the callsite, is not run
until executing the statement.

So, while I guess we could write "case "ALPHA": return
Character::isAlphabetic;" and get the same net result, I haven't
checked if that means we'd go through the hoop of spinning up that call
site at each location (ending up with the same thing) or if javac helps
ensure it'll be done at most once here.

As tests have been thoroughly run on this and time is running out,
I'd prefer contemplating cleaner/nicer ways of writing this particular
patch for 10 if you don't mind.

> Is the long-term solution to make hotspot's lambda initialization even lazier?

I guess it'd be interesting to try make lambdas like these (which
aren't used just after initialization) even lazier by emitting, say,
some thin MutableCallSite that defers real initialization to first use,
but not sure if feasible or if it'd even pay off except for cases like
these where you generate a lot of lambdas / method references but don't
use them right away. I'm sure others have thought more about this than
me.

Somewhat orthogonally I do have plans to continue work on the static
pre-generation jlink plugin I introduced as part of 8086045, along with
other micro-optimizations to the involved java.lang.invoke code. This
helps make each call site lighter to spin up.

AOT might help, too, but stumbles once we actually have to generate a 
new class dynamically, so it's not competing with the things we can
do with jlink currently...

All in all I'm sure we can inch closer and closer to negligible startup
overhead given time and dedication.

/Claes

>
>
>
> On Wed, Feb 1, 2017 at 9:00 AM, Claes Redestad
> <claes.redestad at oracle.com <mailto:claes.redestad at oracle.com>> wrote:
>
>     Hi,
>
>     changes to java.util.regex in 9+119 has been cause for a number of
>     startup
>     regressions due to early use of lambdas, which has both helped motivate
>     work to reduce the overall cost of lambda initialization[1], while
>     in other
>     cases the use of regexes could be reconsidered (VersionProps).
>
>     While this work and workarounds has helped a lot, the changes to
>     java.util.regex can still be the cause of noticeable regressions[2] when
>     using regular expressions that depend on predicates defined in
>     java.util.regex.CharPredicate, simply because of how this class eagerly
>     creates a substantial amount of lambdas during clinit.
>
>     This patch makes the initialization lazy, which improves startup metrics
>     without affecting performance of regular use.
>
>     Bug: https://bugs.openjdk.java.net/browse/JDK-8160302
>     <https://bugs.openjdk.java.net/browse/JDK-8160302>
>     Webrev: http://cr.openjdk.java.net/~redestad/8160302/webrev.01/
>     <http://cr.openjdk.java.net/~redestad/8160302/webrev.01/>
>
>     Thanks!
>
>     /Claes
>
>     PS. Yes, I know final is redundant on static methods, and realized I
>     forgot
>     to remove them after turning constants into methods, but looking at
>     again
>     it seems there's a convention of defining static methods final in
>     this code
>     already, so unless there is a lot of outrage I'd like to defer
>     cleaning up this
>     particular bikeshed.
>
>     [1] https://bugs.openjdk.java.net/browse/JDK-8086045
>     <https://bugs.openjdk.java.net/browse/JDK-8086045>
>     [2] 12-15ms startup regressions due to generating and loading up to 60
>     loaded classes, more early JIT compilations etc..
>
>