On Fri, 27 Oct 2023 22:01:07 GMT, Gerard Ziemski <gziem...@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
