[GR-53596] Dump a native memory tracking (NMT) report on signal

[roberttoyonaga]

Feature request

Please include the following information:

Is your feature request related to a problem? Please describe.
Not related to a problem/bug.

Describe the solution you'd like.
It would be great to be able to dump an NMT report upon receiving a signal (similar to heap dumps).

In regular Java mode, NMT reports can be requested via jcmd. However, since Native Image doesn't have jcmd, a report is only written upon program completion. The usefulness of this is limited because the report will only show a snapshot of the memory usage at the time shutdown hooks are run (the data is kept as an instantaneous snapshot).

When NMT is enabled alongside JFR, JFR events will continuously expose NMT data. This solves the aforementioned problem of only getting a snapshot upon shutdown. However, there is no guarantee that JFR is included in the image along with NMT. JFR also has higher overhead than NMT so users may not want to include it.

SIGUS1 and SIGUSR2 are already taken by heap dumps and compilation dumps respectively. One possibility is to dump an NMT report whenever a heap dump is created. This makes sense because the NMT report fills in memory information not covered by heap dumps. Another possibility is to use SIGUSR1 or SIGUSR2 depending on whether they are already used by other features. This approach is a little messy and only works if all 3 features aren't being used.

Describe who do you think will benefit the most.
GraalVM users and developers can benefit from this.

Describe alternatives you've considered.
Another approach might be to create a SubstrateVM specific MXBean for NMT. This MXBean would be capable of initiating an NMT report dump through remote JMX. Users would need to include the remote JMX feature in their image. Then they could remotely request NMT reports from JDK Mission Control, VisualVM, or some other method of JMX connection.

I don't think this is the best solution since it requires including another feature in the image.

Express whether you'd like to help contributing this feature
I can help work on this, if others think it is a useful addition.

[fernando-valdez]

Thanks for requesting this new feature.
We will keep track in this internal ticket: GR-53596

[roberttoyonaga]

@christianhaeubl how do you feel about the proposed ideas?

[christianhaeubl]

Dumping NMT data on SIGUSR1 sounds reasonable. In the long run, I think that we should try to move away from the signal-based approach (there is no good way to specify which data should be dumped).

[roberttoyonaga]

Yes, there wouldn't be a way of choosing whether to dump the heap or NMT, if both are enabled. For now, I'll work on always dumping both.

I also think it would be a good idea to write the report to a file location specified at runtime (similar to a .jfr file), instead of only as console output.