JDK-8180068: Access of mark word should use oopDesc::mark_offset_in_bytes() instead of '0' for sparc & arm
Tatton, Jason
jptatton at amazon.com
Fri Aug 14 19:26:15 UTC 2020
Hi Aleksey,
Thanks for having a look into this. I was mistaken in what these calls were doing, thank you for explaining this. I'm not able to find any other potential instances where 'oopDesc::mark_offset_in_bytes()' should be used. The bug is a few years old, so perhaps the codebase has naturally evolved in the intervening time to resolve this?
Unless anyone can advise on other instances which I should change, I'd advise closing the bug?
-Jason
-----Original Message-----
From: Aleksey Shipilev <shade at redhat.com>
Sent: 14 August 2020 08:22
To: Tatton, Jason <jptatton at amazon.com>; hotspot-compiler-dev at openjdk.java.net
Subject: RE: [EXTERNAL] JDK-8180068: Access of mark word should use oopDesc::mark_offset_in_bytes() instead of '0' for sparc & arm
On 8/14/20 1:02 AM, Tatton, Jason wrote:
> I have a cleanup to submit. Please review the following patch:
> https://bugs.openjdk.java.net/browse/JDK-8180068
> http://cr.openjdk.java.net/~phh/8180068/webrev.00/
>
> The code change is very straightforward, simply a substitution of '0' with 'oopDesc::mark_offset_in_bytes()' in the relevant 6 locations.
No, wait. None of these look relevant:
*) The uses in load_heap_oop are the _load addresses_. They are naturally just *(obj + 0). This is not loading the mark word.
*) The uses in try_resolve_jobject is decoding the JNI handle, "0" is valid there. This is not loading the mark word. See the native implementation in JNIHandles::resolve_impl that ends up loading off the dereferenced handle via:
inline oop* JNIHandles::jobject_ptr(jobject handle) {
assert(!is_jweak(handle), "precondition");
return reinterpret_cast<oop*>(handle); }
--
Thanks,
-Aleksey
More information about the hotspot-compiler-dev
mailing list