RFR: 8160302: Reduce number of lambdas created when loading java.util.regex.Pattern
martinrb at google.com
Wed Feb 1 19:48:28 UTC 2017
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:
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>
> 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, 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 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/
> 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
> particular bikeshed.
>  https://bugs.openjdk.java.net/browse/JDK-8086045
>  12-15ms startup regressions due to generating and loading up to 60
> loaded classes, more early JIT compilations etc..
More information about the core-libs-dev