RFR: JDK-8318636: Add jcmd to print annotated process memory map [v4]

[Thomas Stuefe]

On Fri, 27 Oct 2023 22:01:07 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Fix spelling
>>  - timeout fuse
>>  - Feedback Johan
>
> src/hotspot/share/services/memMapPrinter.cpp line 294:
> 
>> 292:   // the absolute runtime of printing to blocking other VM operations too long.
>> 293:   const jlong timeout_at = os::javaTimeNanos() +
>> 294:                            ((jlong)(SafepointTimeoutDelay * NANOSECS_PER_MILLISEC) / 2);
> 
> Is AbortVMOnSafepointTimeoutDelay/2 timeout useful for real world cases?
> 
> I assume the client who would need this feature, would need it for a reason and that means memory hungry processes?
> 
> Instead of blocking VM and having to use the timeout, can we:
> 
> A. take a snapshot of NMT virtual memory region and process it without blocking the VM
> 
> B. divide this process into smaller chunks, each of which will be guaranteed to finish before AbortVMOnSafepointTimeoutDelay triggers
> 
> C. temporarily increase AbortVMOnSafepointTimeoutDelay and revert it back afterwords?
> 
> In case A,B we would get back a very close, but not exact view of memory, but wouldn't this be better than getting back precise, but cut off view?
> 
> Case C would give us what the users wants assuming they are OK with waiting a bit longer?
> 
> And adding malloc'ed memory here would be make this issue much worse.

The whole abort-on-timeout thing I added because I run the command in a VMOp, and it runs in a VMOp because I want to print information about GC threads (so, not because of NMT) and I was not sure how long the GC Thread* objects are guaranteed to live. Otherwise, I would not have bothered. AbortVMOnSafepointTimeoutDelay is by default 10 seconds, that is really plenty.

But.... 

Gaaah! :-( I just tried to dump a million mappings in a test and found that the limiting factor is the output stream size of the jcmd bufferedStream. It looks like jcmd buffers the whole $%!& output before sending it over the wire. For hypothetical situations with millions of mappings, this would mean an additional memory footprint in the GB range. Thats quite annoying.

I opened https://bugs.openjdk.org/browse/JDK-8319055 to track that, but have not high hopes of someone actually having the time for it. A potential solution using temporary buffers (an outputStream variant that under the hood buffers its content in a temp file) would be simple, but a bit embarrassing and may need convincing folks.

I need to think about this...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16301#discussion_r1375189381