On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaes...@openjdk.org> wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided >> file name. >> Syntax : GC.heap_dump [options] <filename> >> >> In case the JVM has the XX - flag HeapDumpPath set, we should support an >> additional mode where the <filename> is optional. >> In case the filename is NOT set, we take the HeapDumpPath (file or >> directory); >> >> new syntax : >> GC.heap_dump [options] <filename> .. has precedence over second option >> GC.heap_dump [options] …in case -XX: HeapDumpPath=p is set >> >> This would be a simplification e.g. for support cases where a filename or >> directory is set at JVM startup with -XX: HeapDumpPath=p and writing to the >> path is intended/recommended for usage also in the jcmd case. > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Adjust jcmd manpage, help and globals comment > In a cloud environment using containers, the HeapDumpPath is automatically > set to a file system service to persist the heapdump. However, if a support > engineer or DevOps detects high or increasing memory usage and wants to > trigger a heapdump via jcmd, they would need to specify the filename. This > requires retrieving the set HeapDumpPath from the app environment and copying > it to the jcmd to use the persistent file system. This change can help avoid > the need for an additional copy and paste step, which is prone to errors. Hi Andreas , thanks for the details . Chris, is this understable for you? We indeed had quite a few user complains by cloud env users, that the HeapDumpPath is currently not evaluated in the jcmd case/scenario . ------------- PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2012910338
