Problem with lambda expression in initialization block

[Robert Field]

We are getting multiple test failures from invokevirtual being incorrectly being reported as invokespecial by the vm. But the failures were delayed. So, since we are not yet accepting the new forms, where we will generate invokespecial explicitly, we decided to make invokespecial an immediate error. This appears to be an already existing case, that should work. I will remove the preemptive error. We still very much need to get the invocation type reported correctly.

-Robert


Brian Goetz <brian.goetz at oracle.com> wrote:

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