Method Pointers

[Howard Lovatt]

I have seen your talk and was aware of the sort of code so I should have
been more explicit with my question - sorry.

If method handles were designed to compare by value then when you curry
their argument you would also 'curry' their equals method, no need to
retain the argument. Obviously there is some overhead in currying the
equals, but maybe worth it.

I am very unsure, and hence the original question, about what the overhead
on currying equals would be for a lambda.

On 28 February 2012 07:19, Brian Goetz <brian.goetz at oracle.com> wrote:

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


-- 
  -- Howard.