JDK-8256213 : Remove os::split_reserved_memory
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 16
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-11-11
  • Updated: 2022-06-27
  • Resolved: 2020-12-18
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 17
17 b03Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Description
The ReservedSpace::first_part(..., split=true) API calls os::split_reserved_memory(), which cannot be implemented correctly on Windows (JDK-8253649) and if the underlying memory was not allocate by mmap (JDK-8257040). 

It's used only by CDS (to be removed in JDK-8255917) and heterogenous heap (to be removed in JDK-8256181).

Afterwards, we should remove these two APIs to avoid future misuse.
Comments
Changeset: 06c24e14 Author: Yumin Qi <minqi@openjdk.org> Date: 2020-12-18 20:23:43 +0000 URL: https://git.openjdk.java.net/jdk/commit/06c24e14
18-12-2020

I think if we remove the "hard split" option - we leave ReservedSpace::(last|first)_part() alone but make a split always "shallow", aka split==false - that makes sense but we should then guard against any operations which can only work on real mappings. Mainly os::release_memory(). I imagine giving ReservedSpace an "bool _owns_space " flag, which is false if it is the tail end of a shallow split operation. Then we can assert that no-one calls accidentally ReservedSpace::release() on that thing, since it would not work.
23-11-2020