Looks good to me! On Wed, Feb 1, 2017 at 1:12 PM, Claes Redestad <[email protected]> wrote:
> 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 >> <[email protected] <mailto:[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 >> <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.. >> >> >>
