A peek past lambda

[Brian Goetz]

There's a few layers of this.

My presentation at JVMLS was about the translation technique we plan to 
use to represent lambdas in bytecode.  The "obvious" choice would be to 
use inner classes, but if we do that, we're stuck with that 
representation forever.  Instead, what we do is use an invokedynamic 
call site to embed a "recipe" for the SAM-converted lambda.  The 
language runtime can create the SAM instance with inner classes 
(spinning bytecodes at runtime), with method handles, using VM-private 
"construct an object from raw bits" APIs, etc -- without affecting the 
binary representation in the classfile.  This is key, since then we can 
switch implementation based on performance without switching classfile 
representation.

The prototype version that Remi alludes to uses a version of this 
approach, where it emits invokedynamic code for constructing SAM 
instances, with such a recipe embedded in the static bootstrap parameter 
list.  A step forward!  Once it hits the bootstrap, it just uses proxies 
for now; obviously that's a hack, but we're moving step-by-step towards 
our planned translation strategy.

As Remi alludes, we probably won't use method handles in version 1 of 
the implementation, but the goal of this extra level of indy-rection  is 
to preserve that option for when the MH runtime catches up.  But the 
only thing users will see when that happens is faster code.

On 8/19/2011 1:56 PM, Bob Foster wrote:
> Remi Forax wrote:
>> BTW, Maurizio recently push codes that enables the compiler
> to compile without inner classes.
>
> A step forward for sure!
>
>> For the curious, the current implementation use a j.l.r.Proxy,
> (so don't expect any performance now).
>
> I thought (from the last JVM language summit) that the goal/opportunity was
> to use method handles?
>
> Bob
>