[9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

[Vladimir Ivanov]

John, Paul,

I always welcome valuable suggestions, so here's an update :-)
http://cr.openjdk.java.net/~vlivanov/8032400/webrev.02/

IMO, the test is much cleaner now.

Best regards,
Vladimir Ivanov

On 6/6/14 12:05 PM, Paul Sandoz wrote:
>
> On Jun 6, 2014, at 1:17 AM, John Rose <john.r.rose at oracle.com> wrote:
>
>> Reviewed.
>>
>> This is not a requirement, but I would prefer (in general) to see less test logic in ASM-generated bytecode and more in Java.  I am guessing that the invokeExact call could have been replaced by a simple weakly-typed invoke call in the framing code, and likewise with most of the other invokes (methodType, findSpecial) which are not caller-sensitive.
>
> I was wondering that too, but don't wanna block the push. With some judicious squinting i can work out what is going on. Perhaps if there are other related code fixes in the pipe (e.g. for the FIXME) this test could then be updated if there is time.
>
>
>>
>> — John
>>
>> On Jun 5, 2014, at 3:25 PM, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>>
>>> Thanks for review, Paul.
>>>
>>>>
>>>> Looks ok.
>>>>
>>>> The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-)
>>>>
>>>> Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works?
>>> Good point. Updated webrev:
>>> http://cr.openjdk.java.net/~vlivanov/8032400/webrev.01/
>>>
>
> +1
>
> Paul.
>