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