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 <[email protected]> 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.. >
