On Fri, 15 Mar 2024 06:59:42 GMT, Christoph Langer <clan...@openjdk.org> wrote:
>> src/hotspot/share/runtime/globals.hpp line 565: >> >>> 563: "triggered by jcmd GC.heap_dump without specifying a path, " >>> \ >>> 564: "the path (filename or directory) of the dump file " >>> \ >>> 565: "(defaults to java_pid<pid>.hprof in the working >>> directory)") \ >> >> This incorrectly leads one to conclude that if HeapDumpPath is not specified >> and GC.heap_dump is used without specifying a path, the default will be >> java_pid<pid>.hprof in the working directory. That's not the case. The jcmd >> will produce an error because it requires that either HeapDumpPath be >> specified or a filename be specified as a jcmd argument (I'm not sure why >> the jcmd does not default to java_pid<pid>.hprof) >> >> Also, if you are cleaning up this text, I would suggest changing "is on" to >> "is enabled". Same for HeapDumpGzipLevel below. > > Yes, why not make java_pid<pid>.hprof in the working directory the default if > calling jcmd GC.heap_dump without specifying a path? Would there be any > problem with that approach? Could fill up the working directory if the user is not aware of this default. If you will specify the HeapDumpPath or the filename explicitly you should be aware that you will need enough disk space there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1525976831
