JDK-8303484 : Add the ability to enable NMT at runtime
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 21
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2023-03-01
  • Updated: 2025-04-29
  • Resolved: 2025-04-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdResolved
Related Reports
Blocks :  
JDK-8317453 - NMT: Performance benchmarks are needed to measure speed and memory
Duplicate :  
JDK-8352292 - Implement NMT tags using hashtables
Relates :  
JDK-8303483 - Enable NMT in summary mode by default
Description
The following option needs to be added to the command line to enable NMT:

-XX:NativeMemoryTracking=summary/detail

If this option is not added to the command line at the process launch time, it is not possible to collect NMT output from the process without stopping and re-starting it again. 

It will be helpful if NMT can be enabled on demand at runtime.
Comments
I moved this issue out of 22 into 23. It's blocked by JDK-8317453 Testing with JDK-8317453 reveals that current NMT memory overhead is too much (in Java2Demo) at about 7-9% overhead, to be able to turn it ON without some extra work. We can probably make it work by controlling malloc overhead and making NMT header smaller. It looks doable, but not in 22 timeframe.
09-11-2023
We could use a technique that allows us to store custom data in bits to a pointer called "pointer coloring" (tagging) to let NMT known whether memory has been tracked already or not. Johan did some research and there is hardware support for pointer coloring coming: Johan Sjölén: Intel LAM gives hardware support for this and will be available in Linux 6.2. https://lpc.events/event/11/contributions/1010/attachments/875/1679/LAM-LPC-2021.pdf AMD has a similar solution, which according to LWN is not well-liked by the Linux kernel devs (brittle, slow). ARM has something called "top-byte ignore". Johan Sjölén: LAM support is probably of interest to OpenJDK in general: Applications which reuse the upper bits in addresses must be updated for LAM: • Database. • OpenJDK. • JS VMs. • HTTP servers We could automatically detect support from the OS for these extensions and make NMT dynamically available in that case. This feature would also let us get rid of the transitional pointer table we are currently using for NMT initialization.
16-03-2023
Sure, let's look at this. When os::malloc(N) is called, then NMT asks malloc for N + sizeof(MallocHeader) bytes and receives a pointer p. It then fills out a header in the first sizeof(MallocHeader) bytes and returns a pointer at location p + sizeof(MallocHeader). On os:free(p) NMT will access p-sizeof(MallocHeader) to read the header and put in some stats. Now assume that NMT can be turned on or off dynamically. How does NMT know whether there exists a header before p when os:free() is called? The pointer itself carries no such information. If NMT guesses wrong, it'll either trigger a segmentation fault, or read random memory. So, that's the problem. This problem already exists with NTMPreInit. Before NMT is turned on we record each malloced pointer in a table, so that if NMT is turned on it knows whether a header exists or not for all pointers. > It sounds to me like you might be saying that it is not "easy" to make this work? Is it possible then, if we are willing to do some (involved?) work? Sure, "basically impossible" was a bit pessimistic of me. I believe that this would be a very big code change in NMT and have a big performance impact. Maybe we can find solutions that make a good trade off.
09-03-2023
Could you elaborate on what exactly it is about NMT structure that makes it basically impossible? Can we change the way it is structured to make it possible? It sounds to me like you might be saying that it is not "easy" to make this work? Is it possible then, if we are willing to do some (involved?) work?
09-03-2023
Because of the way that NMT is structured it's basically impossible to enable it dynamically at runtime. However, I think there's a compromise: We could add the possibility of dynamically starting NMT's detailed mode if the summary mode is already enabled at the start. We could also allow a JVM that's started with detailed mode to switch to summary mode.
08-03-2023