Problem with lambda expression in initialization block

[Robert Field]

On 9/16/12 8:36 AM, Brian Goetz 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.

And, as it turns out, this is simply another case of an invokevirtual 
being incorrectly described by the VM as an invokespecial.  Because this 
problem is hitting us so broadly, I have just pushed a hack which 
converts all supposed "invokespecial" to invokevirtual.  This "fixes" 
four failing tests and the submitted program.  This is NOT a solution to 
the problem, because we will need actual invokespecial support soon.

-Robert

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