RFR: JDK-8327769: jcmd GC.heap_dump without options should write to location given by -XX:HeapDumpPath, if set [v8]

[Matthias Baesken]

On Fri, 15 Mar 2024 11:24:53 GMT, Matthias Baesken <mbaesken at 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