JDK-8263464 : NMT: assert in gtest os.release_multi_mappings_vm
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 17
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • Submitted: 2021-03-11
  • Updated: 2023-09-16
  • Resolved: 2023-09-16
Related Reports
Blocks :  
JDK-8308501 - Replacement of SortedLinkList in NMT with other more efficient data structures
Relates :  
JDK-8316393 - gtest/LargePageGtests.java#use-large-pages-sysV fails os.release_multi_mappings_vm
Relates :  
JDK-8267341 - macos attempt_reserve_memory_at(arg1, arg2, true) failure
Relates :  
JDK-8280056 - gtest/LargePageGtests.java#use-large-pages failed "os.release_one_mapping_multi_commits_vm"
Description
If NMT is enabled with gtests (which only can be done with the upcoming JDK-8256844 "Make NMT late-initializable", for which I have a working prototype) we run into new problems with NMT.

One of which is that NMT assumes that we only release regions or parts of regions, but not multiple regions. 

Which is perfectly possible, e.g. we can reserve several adjacent regions and release them in one go. Which is done e.g. in the context of NUMA-aware allocation.

To test such a multi-map release, I added a gtest: os_release_multi_mappings_vm. This one runs into an NMT assert with NMT enabled:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/shared/projects/openjdk/jdk-jdk/source/src/hotspot/share/services/virtualMemoryTracker.cpp:533), pid=264733, tid=264733
#  assert(reserved_rgn->contain_region(addr, size)) failed: Not completely contained

which highlights NMTs inability to deal with that.

This surfaces as an assert in a gtest but is of course not limited to gtests.
Comments
Reclosing as "Not an Issue" instead of Resolving as...
16-09-2023
It is certainly an annoying problem and e.g. causes me to need workarounds recently in gtests I wrote. That said, I can live with us adding a restriction such that only reserved regions can be released as a whole. It would certainly make things easier when virtual memory is backed by SystemV shared mem or on Windows. Its a question of me spending time workarounds vs you doing this patch and us reviewing. I'm unemotional. If you guys rewrite the underlying data structures with JDK-8308501, then maybe we should wait until that one hits.
01-08-2023
This will not be an issue once we finish JDK-8308501 If we ever change our minds and decide not to proceed with JDK-8308501 then we have a fix here https://git.openjdk.org/jdk/pull/13813
31-07-2023
There is an effort to redo the tracking of the reserved/committed regions, so this issue would then become irrelevant. Pausing the work on it.
30-05-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/13813 Date: 2023-05-04 18:57:18 +0000
04-05-2023