JDK-8166583 : Add oopDesc::klass_or_null_acquire()
  • Type: Sub-task
  • Component: hotspot
  • Sub-Component: gc
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2016-09-22
  • Updated: 2021-02-05
  • Resolved: 2016-09-23
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9 Other
8u301Fixed 9 b140Fixed openjdk8u282Fixed
Related Reports
Blocks :  
Description
A concurrent collector may encounter a partially allocated object, e.g. one for which memory has been allocated but it is not yet really an object that the collector can parse or process.  Allocation sets the klass to make the object parsable by the collector.  This is done last of the low-level object creation initializations, with a release store to ensure that happens after necessary initialization (JDK-8165808).

The collector distinguishes between those states (pre-object allocated blob vs actual object) using klass_or_null().  Uses of that function need to ensure the read of the klass occurs before reading other parts of the object, needing an acquire/loadload barrier matching the release_store of the klass.

We don't want to make klass_or_null() quietly have acquire semantics.  We want the acquire semantics to be obvious.  Also, not all callers need acquire semantics, and for some it is probably even wrong.  For example, many uses are in asserts; it would be undesirable to add an acquire barrier only in debug-mode, potentially making races even harder to debug.

So we need a klass_or_null_acquire() that makes the acquire semantics explicit.

Comments
Original patch does not apply to 8u-dev repo after path shuffling due to code changes in the surrounding context. 8u backport RFR thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/012930.html
03-11-2020

Fix Request [8u] As mentioned in [1], JDK-8160369 have not been backported to JDK8u. This is necessary for RMO architectures like aarch64. Reviewing thread: https://mail.openjdk.java.net/pipermail/jdk8u-dev/2020-November/012930.html [1] https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030313.html
03-11-2020