Method Pointers

[Brian Goetz]

As background, check out the talk "From Lambdas to Bytecode" from JVMLS 
this year: http://medianetwork.oracle.com/video/player/1113272510001, 
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 oracle.com>  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.
>>
>>