A peek past lambda
brian.goetz at oracle.com
Fri Aug 19 12:39:33 PDT 2011
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
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?
More information about the lambda-dev