Thanks for those interesting measurements, Sergey. As you point out, the 8024761 changes are be more broadly beneficial to most 292 users, such as Nashorn and JRuby.
So I'm glad to hear they hit near the mark of the specialized tweak. We can keep your tweak in our "back pocket" in case we need the extra boost. But I think further general work (in the JIT) on folding up MH.invoke will close the observable gap. — John On Sep 16, 2013, at 9:22 AM, Sergey Kuksenko <sergey.kukse...@oracle.com> wrote: > Hi John, Brian, > I did evaluation JDK-8024630(my patch) vs JDK-8024761(your patch). > > I did it for lambda linkage vs anonymous classloading. Because of > non-capture lambdas behaviour significantly differ capturing lambdas I > have to measure linkage twice (non-capturing vs capturing). Other > dimension is Tiered vs NonTiered compilation. I checked it on loading > different amount of lambdas (classes) - 1K, 4K, 8K, 16K, 24K, 32K, 64K. > (K=1024) > > > Non-capturing lambda: > - JDK-8024630 is slightly faster (2-3%) than JDK-8024761 on less amount > of lambdas (1K,4K,8K). But starting from 16K JDK-8024761 is faster (also > 2-3%). The same for tiered/non-tiered. > > Capturing lambda: > - Non-tiered compilation show the same behaviour and the same > percentages as non-capturing lambda. In case of TieredCompilation the > initial difference is started from 8% (JDK-8024630 is faster) and became > lower and both RFEs has the same performance from 24K lambdas. > > So looking into my results I'll vote for JDK-8024761 instead of > JDK-8024630. Because of your solution is general and performance > difference is not significant. > > On 09/11/2013 10:18 PM, John Rose wrote: >> Yes, this is a good tactic, but as written it is too much of a point hack >> for lambdas (important though they are). >> >> I have an alternate solution I would like you to measure. It provides a >> fast path for other BSM lookups like Nashorn's, so (if it works well for >> lambda) it is preferable. >> >> I will attach a patch to the bug report. >> >> — John >> >> On Sep 11, 2013, at 9:23 AM, Sergey Kuksenko <sergey.kukse...@oracle.com> >> wrote: >> >>> Please review the webrev at: >>> >>> http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/webrev.00/ >>> >>> LambdaMetafactory is is a quite frequent bootstrap method for >>> invokedynamic in JDK8. >>> We can do direct method (LambdaMetafactory) invocation as fastpath when >>> proved that bootstrap MethodHandle points to LambdaMetafactory. >>> The modification gives +10% - +35% to lambda linkage performance >>> (depends on amount of lambdas). >>> >>> -- >>> Best regards, >>> Sergey Kuksenko >> > > > -- > Best regards, > Sergey Kuksenko
