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

[coleen.phillimore at oracle.com]

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