Method Pointers

[Brian Goetz]

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: 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.
>>>
>>>
>