RFR: 8304442: Defer VirtualMemoryTracker work until reporting

Johan Sjölen jsjolen at openjdk.org
Sat Mar 18 14:57:14 UTC 2023


Hi,

The virtual memory tracker of NMT used to do a lot of heavy linked list calculations when memory was reserved, committed, uncommited or split up. However, the results of these calculations are actually only used when creating a native memory report. Let's not slow down the JVM unnecessarily, we can do this work at time of report instead.

In order to achieve this I've replaced the public API with a work queue:ing solution. We append each work item to a `GrowableArray` and introduce the `commit_events` method to do the actual work, which we call internally when needed.

I measured the gains in efficiency through the use of Valgrind's Cachegrind tool. I ran a `linux-x64` build with the following source code:


public class Test {
    public static void main(String[] args) {
    }
}


These are the total cycles executed by `os::commit` and `os::reserve` as estimated by Valgrind over the entire run of the program. 


os::commit
old         | new         | new / old
935238      | 578979      | 0.62
os::reserve
old         | new         | new / old
53628       | 21825       | 0.41


There should also be some memory savings as a `MemoryEvent` is smaller (64 bytes) than a `ReservedRegion` (96 bytes). That is, until a `commit_events()` occur.

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

Commit messages:
 - Fix tests
 - Delay work through a worklist

Changes: https://git.openjdk.org/jdk/pull/13088/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304442
  Stats: 127 lines in 5 files changed: 97 ins; 1 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/13088.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13088/head:pull/13088

PR: https://git.openjdk.org/jdk/pull/13088


More information about the hotspot-runtime-dev mailing list