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

[Volker Simonis]

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