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
