improve lambda performance using method handle proxy

On 9/28/2012 1:15 PM, Christian Thalinger wrote:

On Sep 27, 2012, at 6:39 PM, Brian Goetz <brian.goetz@oracle.com> wrote:

Actually, the plan (which could change with more information) is to ship
with the inner class version. The proxy version "worked", so yes, the
CallSite should be right. But that version has not been actively
developed/maintained, and is currently disabled.

I was not aware of InvokerBytecodeGenerator, and there is some overlap,
there is definitely overlap with what InvokerBytecodeGenerator uses:
sun/invoke/util/Wrapper

What we might eventually switch to is an as-yet-unwritten MF implementation that would spin one class (or maybe two, one serializable and one not) per functional interface type, whose constructor takes an MH. So we'd still be spinning bytecode.

The performance of the MH Proxy version is beyond awful. Sergey had to explicitly note in his report that the throughput was in ops/sec, not MOps/sec, and the legend was not a typo :)

Sigh. That hurts. Can I reproduce the results to see where the bottleneck is? Or do you know where it is?

-- Chris


On Sep 28, 2012, at 4:49 PM, Christian Thalinger <christian.thalinger@oracle.com> wrote:


On Sep 28, 2012, at 10:19 AM, Brian Goetz <brian.goetz@oracle.com> wrote:

If you edit LambdaMetafactory, at the top you can select which one you want:

 private static final String whichMetafactory;
 static {
     /*** development-time meta-factory switching
     String s = System.getProperty("lambda.metafactory", "innerClass");
     whichMetafactory = !s.isEmpty() ? s : "innerClass";
     ***/
     whichMetafactory = "innerClass";
 }

We're currently hard-coded to inner-class, but just switch to "mhProxy". Then just run any code that uses lambdas.

Right. I was referring to "any code" ;-) So, I have to build a lambda workspace and then run a small benchmark?

-- Chris


Sergey may be able to help w the benchmark.

Sent from my iPhone