A peek past lambda

[Paul Benedict]

Regarding the translation technique, will Oracle's choice to construct
SAM instances be mandatory for all compiler vendors? Or can compiler
vendors choose between proxies or method handles or whatever solution
they find best?

On Fri, Aug 19, 2011 at 2:39 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 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
>>
>
>