RFR(XS) [10]: 8184672: [ppc64] The fix for '8174749: Use hash table/oops for MemberName table' is broken on ppc64

[Volker Simonis]

No problem. Thanks for the quick review and also for applying your
changes to our platforms. We really appreciate that!

Regards,
Volker


On Fri, Jul 14, 2017 at 10:05 PM,  <coleen.phillimore at oracle.com> wrote:
>
> Hi Volker,
> This looks good.   Sorry for the breakage- I thought my change was trivial
> and couldn't possibly break :0
> Thanks!
> Coleen
>
>
> On 7/14/17 11:41 AM, Volker Simonis wrote:
>>
>> Hi,
>>
>> can somebody please review the following small, ppc64-only change:
>>
>> http://cr.openjdk.java.net/~simonis/webrevs/2017/8184672
>> https://bugs.openjdk.java.net/browse/JDK-8184672
>>
>> The change for "JDK-8174749: Use hash table/oops for MemberName table"
>> introduced a new indirection for the 'vmtarget' field in
>> java.lang.invoke.MemberName. 'vmtarget' was previously directly stored
>> in MemberName and is now a field of the new class ResolvedMethodName,
>> an object of which is now stored in MemberName.
>>
>> The change contained some architecture-specific code which updated the
>> HotSpot to be aware of the new indirection (i.e. instead of loading
>> 'vmtarget' directly from a MemberName object the code now has to first
>> load the ResolvedMethodName object from MemeberName and subsequently
>> the 'vmtarget' field from the ResolvedMethodName object.
>>
>> This code is trivial, but on ppc64, the new version has incorrectly
>> 'misused' the register which contained the MemberName, as storage for
>> the intermediate ResolvedMethodName object. If the MemberName object
>> was stored in an argument register, that register was overwritten in
>> MethodHandles::generate_method_handle_dispatch (when generating the
>> intrinsics for MethodHandle.linkToStatic or
>> MethodHandle.linkToSpecial) and could lead to the following error down
>> the call chain:
>>
>> # Internal Error
>> (jdk10-hs/hotspot/src/cpu/ppc/vm/macroAssembler_ppc.cpp:5493),
>> pid=20194, tid=20202
>> # guarantee(false) failed: PPC assembly code requires stop: MemberName
>> required for invokeVirtual etc.
>>
>> V [libjvm.so+0x14a0600] stop_on_request(int, char const*)+0x7c
>> J 110
>> java.lang.invoke.MethodHandle.linkToStatic(Ljava/lang/Object;IILjava/lang/invoke/MemberName;)Ljava/lang/Object;
>> java.base at 10-internal (0 bytes) @ 0x00000fff852d9774
>> [0x00000fff852d9700+0x0000000000000074]
>> J 309 c2
>> java.lang.invoke.LambdaForm$MH.invoke(Ljava/lang/Object;J)Ljava/lang/Object;
>> java.base at 10-internal (161 bytes) @ 0x00000fff852fea98
>> [0x00000fff852fe900+0x0000000000000198]
>> J 308 c2
>> java.lang.invoke.LambdaForm$MH.linkToTargetMethod(JLjava/lang/Object;)Ljava/lang/Object;
>> java.base at 10-internal (9 bytes) @ 0x00000fff852fe23c
>> [0x00000fff852fe200+0x000000000000003c]
>> j LambdaForm.foo(J)Ljava/lang/String;+86
>> j LambdaForm.main([Ljava/lang/String;)V+8
>>
>> The fix for the problem is trivial. Just use the final destination
>> register for 'vmtarget' also as intermediate storage for the
>> ResolvedMethodName object (thus leaving the register holding the
>> MemberName reference untouched).
>>
>> Thank you and best regards,
>> Volker
>
>