-
Enhancement
-
Resolution: Fixed
-
P4
-
16
-
b09
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-8289576 | 17.0.5 | Vladimir Kempik | P4 | Resolved | Fixed | b01 |
Today, NMT is of limited use due to the following restrictions:
- NMT cannot be used if the hotspot is embedded into a custom launcher unless the launcher actively cooperates. Just creating and invoking the JVM is not enough, it needs to do some steps prior to loading the hotspot. This limitation is not well known (nor, do I believe, documented). Many products don't do this, e.g., you cannot use NMT with IntelliJ. For us at SAP this problem limits NMT usefulness greatly since our VMs are often embedded into custom launchers and modifying every launcher is impossible.
- Worse, if that custom launcher links the libjvm statically there is just no way to activate NMT at all. This is the reason NMT cannot be used in the gtestlauncher.
- Related to that is that we cannot pass NMT options via JAVA_TOOL_OPTIONS and -XX:Flags=<file>.
- The fact that NMT cannot be used in gtests is really a pity since it would allow us to both test NMT itself more rigorously and check for memory leaks while testing other stuff.
The reason for all this is that NMT initialization happens very early, on the first call to os::malloc(). And those calls happen already during dynamic C++ initialization - a long time before the VM gets around parsing arguments. So, regular VM argument parsing is too late to parse NMT arguments.
The current solution is to pass NMT arguments via a specially prepared environment variable: NMT_LEVEL_<PID>=<NMT arguments>. That environment variable has to be set by the embedding launcher, before it loads the libjvm. Since its name contains the PID, we cannot even set that variable in the shell before starting the launcher.
All that means that every launcher needs to especially parse and process the NMT arguments given at the command line (or via whatever method) and prepare the environment variable. java itself does this. This only works before the libjvm.so is loaded, before its dynamic C++ initialization. For that reason, it does not work if the launcher links statically against the hotspot, since in that case C++ initialization of the launcher and hotspot are folded into one phase with no possibility of executing code beforehand.
And since it bypasses argument handling in the VM, it bypasses a number of argument processing ways, e.g., JAVA_TOOL_OPTIONS.
- backported by
-
JDK-8289576 Make NMT late-initializable
- Resolved
- duplicates
-
JDK-8263378 NMT options not accepted via JAVA_TOOL_OPTIONS of -XX:Flags
- Closed
- relates to
-
JDK-8258917 NativeMemoryTracking is handled by launcher inconsistenly
- Resolved
-
JDK-8186483 [AOT] jaotc cannot be executed with NMT option
- Closed
-
JDK-8275207 Enabling of native memory tracking using NMT_LEVEL causes to JVM crash
- Closed
-
JDK-8290046 NMT: Remove unused MallocSiteTable::reset()
- Resolved
-
JDK-8296443 NMT: Remove cmdline_tracking_level handling code
- Resolved
-
JDK-8042469 Launcher changes for native memory tracking scalability enhancement
- Closed
-
JDK-8267341 macos attempt_reserve_memory_at(arg1, arg2, true) failure
- Resolved
-
JDK-8273877 os::unsetenv unused
- Resolved
- links to
-
Commit openjdk/jdk17u-dev/774213fd
-
Commit openjdk/jdk/eec64f55
-
Review openjdk/jdk17u-dev/496
-
Review openjdk/jdk/4874