[GR-56600] Track virtual memory with native memory tracking (NMT)

[roberttoyonaga]

Summary

Related Issue: #8629

This pull request adds virtual memory tracking to NMT. Previously, NMT only tracked mallocs and was missing information about virtual memory.

The main component of this PR is the VirtualMemoryTracker class which is based on virtualMemoryTracker.cpp in Hotspot. Since commits and uncommits may partially (or not at all) overlap with existing committed regions, it is necessary to keep an internal model of virtual memory in use. NativeMemoryTracking delegates virtual memory tracking duties to VirtualMemoryTracker which maintains this internal model. This is the same as how memTracker.hpp delegates to virtualMemoryTracker.cpp in Hotspot. NativeMemoryTracking remains the the main interface to record and retrieve tracking data, whileVirtualMemoryTracker and associated classes are only used by NMT internally.

Tracking virtual memory usage before the image heap is mapped requires special handling. We can't use the NativeMemoryTracking image singleton yet so we must instead use unmanaged memory and stack memory to temporarily record virtual memory usage. Once the image heap is mapped, the temporary records can be properly committed to tracking. NmtPreImageHeapData is used to enqueue records of pre-image-heap reserves/commits.

More details:

• All virtual memory accounting operations are protected by a spinlock. I don't think this should have an impact on performance since changes in virtual memory usage should be infrequent. memTracker.hpp uses the same approach to protect virtual memory accounting.
• Virtual memory peak tracking is also added.
• Updated NMT report printing to make it more similar to OpenJDK:

Native memory tracking

Total
        (reserved=30200KB, committed=29688KB)
        (malloc=32KB, count=77)
        (peak malloc=10518KB, count at peak=528)
        (mmap: reserved=30168KB, committed=29656KB)
        (mmap: peak reserved=30168KB, peak committed=29656KB)
...
JFR
        (reserved=16KB, committed=16KB)
        (malloc=16KB, count=2)
        (peak malloc=10495KB, count at peak=453)
        (mmap: reserved=0KB, committed=0KB)
        (mmap: peak reserved=0KB, peak committed=0KB)
...

[roberttoyonaga]

Rebased, fixed conflicts, and added a couple commits to provide windows support and improve NMT report printing.

[christianhaeubl]

@roberttoyonaga : thanks for the PR, however I think that the complexity of this PR outweighs its benefits at the moment.

We can probably get almost the same functionality with a far simpler change:

• VirtualMemoryProvider is primarily used for the Java heap (image heap + runtime heap)
• For the Java heap, the garbage collector knows in detail how much memory is reserved and committed (see HeapAccounting). We probably don't expose all the needed information at the moment but it should be rather simple to add.

So, I think that something like the above would be the better approach for now. However, I would still suggest to keep your branch around as things may change in the future.

[roberttoyonaga]

Hi @christianhaeubl, ok I'll work on another simplified PR. I'll get rid of the NmtVirtualMemoryTracker class and retrieve the committed/reserved statistics from the GC directly. The reason I didn't take that approach originally, is because I wanted to avoid making assumptions based on the current implementation. The more general approach here provides more flexibility, but I agree that it might be unnecessarily complicated for how SVM uses virtual memory currently.

[roberttoyonaga]

Hi @christianhaeubl, I've made a PR for the simplified version here: #9505

[christianhaeubl]

I am closing this PR in favor of #9505.