RFR: 8356228: NMT does not record reserved memory base address correctly

Gerard Ziemski gziemski at openjdk.org
Tue Jun 10 19:52:27 UTC 2025


On Tue, 10 Jun 2025 11:23:14 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> The problem here stems from the following facts:
> 1) When requesting an aligned virtual memory, the size may be extended to meet the alignment requirements. The extra size from the two ends are released afterward. 
> 2) NMT ignores tracking of releasing CDS regions that are contained in larger regions, because they should be in a specific order.
> 3) In linux-aarch64 environment, the alignment size is 64K, reserve operations may fall into cases as 1) above.
> 
> So, if ArchiveBuffer memory is reserved with CDS tag, there might be some released regions that NMT ignored and then later complains their intersection with other regions (e.g., thread stack regions observed in the issue).
> 
> Solution is to reserve the memory with no tag (mtNone) and if it succeeds change the tag of the region to CDS for further trackings.
> 
> Tests:
> linux-x64: runtime/NMT jtreg tests passed
> linux-aarch64: tier1 to tier3 passed

src/hotspot/share/cds/archiveBuilder.cpp line 346:

> 344:   // During an aligned reserve, some extra sub-regions of the memory region may be released due to alignment requirements.
> 345:   // NMT will ignore releasing sub-regions (i.e., contained in other regions) that have mtClassShared tags.
> 346:   MemTracker::record_virtual_memory_tag(rs, mtClassShared);

Is it possible to capture this logic in a test, so we can always check for this behavior?

Where in the code do we release and check for the special case of `mtClassShared`?

I'm not 100% sure I understand why we have to first reserve with `mtNone` and only then change it to `mtClassShared`. Why can't we reserve with `mtClassShared` right from the start?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/25719#discussion_r2138658913


More information about the hotspot-runtime-dev mailing list