RFR (S): 8188145: MethodHandle resolution should follow JVMS sequence of lookup by name & type before type descriptor resolution
vladimir.x.ivanov at oracle.com
Tue Dec 19 18:39:41 UTC 2017
Thanks, Paul & Vladimir!
> The logic looks good to me: resolving the member name, before resolving it’s type.
Want to elaborate here a bit.
Symbolic info from CP entry is placed into a freshly created MemberName
instance. It is done that way to piggyback on logic in
MethodHandles::resolve_MemberName() to do proper member resolution.
An alternative would be to factor out relevant logic from
resolve_MemberName() and pass symbolic info directly, but I tried that
and wasn't satisfied with the results.
After resolution succeeds, type descriptor from member name is resolved.
And that's the *only* piece which is used from resolved member name.
Resolved member name is thrown away and JDK will repeat member
resolution from the very beginning.
Type descriptor resolution is performed on the member name to simplify
dispatching logic on descriptor format (method vs field).
Obvious performance improvement would be to reuse resolved member name
and pass it into JDK to construct the method handle right out of it, but
I decided to play it safe and keep the fix simple by preserving all the
existing checks during MH constant construction.
PS: another direction I explored was to pass *symbolic* type descriptor
(as a String and not MethodType/Class) into JDK and delay its resolution
till member resolution is over in MethodHandles::resolve_MemberName().
But it turned out to be very fragile because any call of
MemberName::getType() in between triggers type resolution (and it
happens in surprising places, like checking member name equality).
>> On 19 Dec 2017, at 07:37, Vladimir Ivanov <vladimir.x.ivanov at oracle.com> wrote:
>> When resolving MethodHandle constants JVM eagerly resolves type descriptor before doing upcall into JDK which performs method/field resolution later (using MethodHandleNatives.resolve on symbolic MemberName).
>> The problem is that according to JVMS, member resolution (and all exceptions it throws) should precede type descriptor resolution.
>> Proposed fix does member & type descriptor resolution from JVM first and then passes symbolic info into JDK (MHN.linkMethodHandleConstant).
>> The fix is conservative, since JDK repeats method/field resolution on a freshly created MemberName from symbolic info. But considering there are additional security-sensitive checks on JDK side, I decided to leave all optimizations for future enhancements.
>> Testing: hs-precheckin-comp, hs-tier1, hs-tier2
>> Best regards,
>> Vladimir Ivanov
More information about the hotspot-runtime-dev