Problem with lambda expression in initialization block

[Brian Goetz]

If MHI reports it as an "invokespecial" MH, it had better be invocable with invokespecial, and we have examples where the VM is returning so-marked methods when they are not.  That's a bug.  Now, its possible this situation may or may not be the same issue.  But the latest 292 merge definitely introduced MHI bugs of this form.  

On Sep 16, 2012, at 11:29 AM, Remi Forax wrote:

> On 09/16/2012 04:51 PM, Brian Goetz wrote:
>>> So AbstractValidatingLambdaMetafactory.validateMetafactoryArgs should be
>>> changed to allow
>>> lambda that are constructed with a super call.
>> 
>> No, if your theory is correct (and we've seen this bug elsewhere), its a VM bug introduced in the new 292 implementation.
>> 
>> We use the MethodHandle-cracking API DanH spoke about at JVMLS. If MethodHandleInfo reports that a MH is of kind REF_special, then it had better be invokable with invokespecial.  If the check in AVLMF were to pass this through (we tried it), the invoke would fail.
>> 
>> Its a straight bug in the new MethodHandleInfo.
> 
> No, if there is a bug, it's because the invoke had fail.
> 
> If you have something like,
> class A {
>  private void foo() {
>     ...
>  }
> 
>  private void bar() {
>     foo();    // here the compiler is free to use invokespecial instead of invokevirtual
>  }
> }
> 
> What's happen with MethodHandleInfo is exactly the same, the VM knows that because
> the class is final, the lambda method generated by javac can not be overriden.
> So even if you create your method handle with a findVirtual, the VM is free to encode it
> as if it was a findSpecial and the MethdoHandleInfo API is an API that crack method handle
> not an API that reflects the way a method handle is created, otherwise the VM will have to
> store metadata in the method handle only because it can be cracked making method handle
> less lightweight. Because dynamic langages can create one hundred thousand method handles
> (think big rail application), each method handle has to be as lightweight as possible.
> 
> cheers,
> Rémi
>