RFR(XS) : 8184672: [ppc64] The fix for '8174749: Use hash table/oops for MemberName table' is broken on ppc64
volker.simonis at gmail.com
Mon Jul 17 15:58:14 UTC 2017
No problem. Thanks for the quick review and also for applying your
changes to our platforms. We really appreciate that!
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
> On 7/14/17 11:41 AM, Volker Simonis wrote:
>> can somebody please review the following small, ppc64-only change:
>> 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
>> 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.base at 10-internal (0 bytes) @ 0x00000fff852d9774
>> J 309 c2
>> java.base at 10-internal (161 bytes) @ 0x00000fff852fea98
>> J 308 c2
>> java.base at 10-internal (9 bytes) @ 0x00000fff852fe23c
>> 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,
More information about the hotspot-dev