JDK-8024630 : Direct LambdaMetaFactory invocation from CallSite significantly improves lambda linkage performance
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang.invoke
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2013-09-11
  • Updated: 2013-10-23
  • Resolved: 2013-10-23
Related Reports
Duplicate :  
Relates :  
Description
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).

Comments
My understanding is that John's fix is a generalization of Sergey's. Sergey, do you agree?
23-10-2013

Yes, I agree.
23-10-2013

Can this issue be closed? Sergey's evaluation: the fix for JDK-8024761 is sufficient.
22-10-2013

Needs sponsor.
21-10-2013

I did evaluation JDK-8024630 vs JDK-8024761. 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.
16-09-2013

here is webrev too http://cr.openjdk.java.net/~skuksenko/jsr335/8024630/
12-09-2013

Attached patch (in zip file) contains portions of performance work for Nashorn which are also relevant to this problem.
12-09-2013

Could you upload the webrevs to cr.openjdk.java.net and add a link to the bugs? It would be easier to review the changes.
11-09-2013

Attached webrev contains full fix. Please review.
11-09-2013