Method Pointers

Brian Goetz brian.goetz at
Mon Feb 27 12:19:19 PST 2012

Correction: example should be "if (!s.isEmpty()) ..."

On 2/27/2012 3:03 PM, Brian Goetz wrote:
> As background, check out the talk "From Lambdas to Bytecode" from JVMLS
> this year:,
> which outlines the dynamic strategy for translation.  I'm currently
> working on an updated document describing the translation strategy and
> options.
> One obvious translation strategy is inner classes, but it would be
> shameful if that's all we were ever able to do.  Though inner classes
> can easily be tweaked to get direct access to captured variables since
> they are stored as fields, which is probably where the widespread "it
> would cost nothing" intuition is coming from.
> But another strategy is method handles, which offers the VM more
> latitude to perform optimizing translations without generating extra
> classes.  So, for example, if you curry arguments onto a desugared
> lambda body with MethodHandles.insertArguments, the VM has the
> opportunity to use techniques like partial application to produce an
> optimized partially bound result.  The cost of that is you cannot
> necessarily retrieve the arguments that were bound into the method
> handle, since they may no longer exist in a form that is retrievable.
> As an example, take the method
>     boolean foo(String s) {
>       if (s.isEmpty()) { return doSomething(s); }
>       else return false;
>     }
> If you have a method handle for foo, and do
>      foo.insertArguments("")
> the VM is within its rights to simply hand you back a method handle for
> "return false" and does not hold onto the bound string argument, which
> then opens the doors to further optimizations.  But if we saddle it with
> the requirement to remember everything that was bound to it, we lose
> that opportunity for optimization.
> On 2/27/2012 2:51 PM, Howard Lovatt wrote:
>> The method pointers are probably doing something I don't understand judging by your comment that arguments need to be reconstructed. Do you have time to expand on the comment?
>> Cheers,
>>    -- Howard.
>> Sent from my iPad
>> On 28/02/2012, at 2:57 AM, Brian Goetz<brian.goetz at>   wrote:
>>>> On the other hand, I really like Howard's proposition of comparing
>>>> lambdas by checking equity of each captured value. If I understand
>>>> correctly, it seems that a proper equals() method could be generated
>>>> without any runtime costs
>>> The part about "no runtime costs" is not correct.  Requiring a "proper"
>>> equals method imposes the requirement that the captured args be able to
>>> be reconstituted on demand, which likely has additional costs for
>>> capture and/or footprint.
>>> I'm not saying this is not desirable, I'm just saying don't kid yourself
>>> that its free.

More information about the lambda-dev mailing list