JDK-8274322 : Problems with oopDesc construction
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 18
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-09-25
  • Updated: 2021-10-04
  • Resolved: 2021-10-01
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 18
18 masterFixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
When allocating a new oop we allocate memory for an oopDesc, fill in certain parts of that memory, and cast the memory to an oop.

This means we never call an oopDesc constructor. That approach to "constructing" an oopDesc is only valid if its default constructor is trivial.  And it can only be trivial if all it's members have trivial default constructors.

C++14 3.8 Object lifetime, paragraph 1, says

The lifetime of an object of type T begins when:
— storage with the proper alignment and size for type T is obtained, and
— if the object has non-trivial initialization, its initialization is complete.

But oopDesc has a markWord member, and markWord's default constructor is not trivial:

markWord() { /* uninitialized */ }

As a result, the lifetime of the oopDesc object never begins, and accesses via ordinary oopDesc member functions are invalid.  We may not have been running afoul of this because we've been building with -fno-lifetime-dse since JDK-8151841.

The intent of the existing constructor is to be "trivial", but this definition preceeds the availability of C++11/14 default definitions in HotSpot.  The default markWord constructor should be changed to be trivial.

Comments
Changeset: 2e690ba8 Author: Kim Barrett <kbarrett@openjdk.org> Date: 2021-10-01 00:25:35 +0000 URL: https://git.openjdk.java.net/jdk/commit/2e690ba8bda30902f1188cabad63fb60f4eb828f
01-10-2021

An alternative would be to add factory functions that invoke private constructors using placement new.
27-09-2021

This change doesn't remove the need for -fno-lifetime-dse elsewhere. For example, the mechanism around ResourceObj::set_allocation_type depends on setting a member of an as-yet unconstructed ResourceObj.
26-09-2021