JDK-8349971 : NMT should allow to repaint memory with different tags
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2025-02-13
  • Updated: 2025-08-15
  • Resolved: 2025-08-15
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.
Other
tbdResolved
Related Reports
Duplicate :  
JDK-8337217 - Port VirtualMemoryTracker to use VMATree
Description
Ran into this while working on JDK-8330174.

NMT cannot handle ReservedSpace::partition(). I prefer that API over first_part/last_part because it leads to clearer code and expresses what I need to do.

To make matters worse, with os::map_memory we require a valid tag. There is no way to specify "just use whatever tag the memory is already tagged with". Or, alternatively, "I know I remap existing mappings (or parts thereof) and that is okay". No, mapping with os::reserve_memory and then remapping part of that with os::map_memory makes NMT assert if os::map_memory uses a different tag.

A "repaint" API would be most useful, simple, and versatile - the ability to re-tag existing memory ranges in NMT with different tags without having to jump through these ridiculous loopholes to appease NMT for something that is perfectly valid to do on the OS side of things.

(I hope things get better once we migrated to VMATree)
Comments
[~azafari] I don't have time to test this, but I trust you. Very good! Feel free to close this one as duplicate to the big VMATree one.
15-08-2025
Dear [~stuefe], This feature is implicitly implemented after use of VMATree in NMT which is integrated now. More precisely, the MemTracker::record_virtual_memory_tag(address base, size_t size, MemTag tag) does this. All the contained sub-regions within the [base, base + size) will be accounted for the new mem_tag. This means that all the reserved/committed amount os the sub-regions will be decreased from old tag(s) and accounted for the new one. If this fulfils the requirements in this issue, we can close this.
15-08-2025
As you say, I really think that VMATree will basically solve this by default.
19-02-2025