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

[Martin Buchholz]

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. Is the long-term solution to make hotspot's lambda
initialization even lazier?



On Wed, Feb 1, 2017 at 9:00 AM, Claes Redestad <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
> Webrev: 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
> [2] 12-15ms startup regressions due to generating and loading up to 60
> loaded classes, more early JIT compilations etc..
>