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