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

[Martin Buchholz]

Looks good to me!

On Wed, Feb 1, 2017 at 1:12 PM, Claes Redestad <claes.redestad at oracle.com>
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
>> <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..
>>
>>
>>