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@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@10-internal (161 bytes) @ 0x00000fff852fea98 [0x00000fff852fe900+0x0000000000000198]
J 308 c2 java.lang.invoke.LambdaForm$MH.linkToTargetMethod(JLjava/lang/Object;)Ljava/lang/Object; java.base@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).