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

[Volker Simonis]

Thanks Goetz!

I've just pushed the change,
Volker


On Tue, Jul 18, 2017 at 4:07 PM, Lindenmaier, Goetz
<goetz.lindenmaier at sap.com> wrote:
> Hi Volker,
>
> yeah, this fixes the overwriting of the method register.
> Looks good.
>
> Best regards,
>   Goetz.
>
>> -----Original Message-----
>> From: hotspot-dev [mailto:hotspot-dev-bounces at openjdk.java.net] On
>> Behalf Of Volker Simonis
>> Sent: Freitag, 14. Juli 2017 17:42
>> To: HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>> Subject: RFR(XS) [10]: 8184672: [ppc64] The fix for '8174749: Use hash
>> table/oops for MemberName table' is broken on ppc64
>>
>> 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/i
>> nvoke/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/O
>> bject;
>> 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