Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
On Jun 6, 2014, at 3:25 AM, Paul Sandoz wrote: > > On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov > wrote: > >> 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. >> > > Yes, I like it, easier to understand. Exactly what I was hoping for. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
On Jun 6, 2014, at 11:31 AM, Vladimir Ivanov wrote: > 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. > Yes, I like it, easier to understand. Paul. signature.asc Description: Message signed with OpenPGP using GPGMail ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
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 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 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. ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
On Jun 6, 2014, at 1:17 AM, John Rose 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 > 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. signature.asc Description: Message signed with OpenPGP using GPGMail ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
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. — John On Jun 5, 2014, at 3:25 PM, Vladimir Ivanov 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/ > > Best regards, > Vladimir Ivanov > ___ > mlvm-dev mailing list > mlvm-dev@openjdk.java.net > http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
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/ Best regards, Vladimir Ivanov ___ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
Re: [9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
On Jun 4, 2014, at 5:25 PM, Vladimir Ivanov
wrote:
> https://bugs.openjdk.java.net/browse/JDK-8032400
> http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/
>
> Consider the following hierarchy:
> class T1{int m() { return 1; }}
> class T2 extends T1 { static int m() { return 2; }}
> class T3 extends T2 {int m() { return 3; }}
>
> T3 has a method, which does the following using method handles:
> T3::test { invokespecial T1.m() T3 }
>
> T1.m lookup attempt from T3 ends up as T2.m lookup, but it fails since T2 has
> static method with the same signature. Lookup.getDirectMethodCommon doesn't
> expect such failure and throws InternalError.
>
> JVMS specification states the following:
> // JVMS 6.5: invokespecial
> // ... 2. Otherwise, if C is a class and has a superclass, a search
> // for a declaration of an instance method with the same name and
> // descriptor as the resolved method is performed, starting with the
> // direct superclass of C and continuing with the direct superclass
> // of that class, and so forth, until a match is found or no further
> // superclasses exist. If a match is found, then it is the method to
> // be invoked.
>
> The fix is to comply with the spec and search upper in the class hierarchy if
> lookup attempt fails.
>
> Testing: regression test, jdk/test/java/lang/invoke, tests on access checks.
>
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?
Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
[9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method
https://bugs.openjdk.java.net/browse/JDK-8032400
http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/
Consider the following hierarchy:
class T1{int m() { return 1; }}
class T2 extends T1 { static int m() { return 2; }}
class T3 extends T2 {int m() { return 3; }}
T3 has a method, which does the following using method handles:
T3::test { invokespecial T1.m() T3 }
T1.m lookup attempt from T3 ends up as T2.m lookup, but it fails since
T2 has static method with the same signature.
Lookup.getDirectMethodCommon doesn't expect such failure and throws
InternalError.
JVMS specification states the following:
// JVMS 6.5: invokespecial
// ... 2. Otherwise, if C is a class and has a superclass, a search
// for a declaration of an instance method with the same name and
// descriptor as the resolved method is performed, starting with the
// direct superclass of C and continuing with the direct superclass
// of that class, and so forth, until a match is found or no further
// superclasses exist. If a match is found, then it is the method to
// be invoked.
The fix is to comply with the spec and search upper in the class
hierarchy if lookup attempt fails.
Testing: regression test, jdk/test/java/lang/invoke, tests on access
checks.
Thanks!
Best regards,
Vladimir Ivanov
___
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
