On Wed, 27 Mar 2024 13:44:42 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 java.1 man page

Notwithstanding that there may be cases where this change would be convenient, 
I really don't like this coupling between the jcmd behaviour and a -XX flag 
that is intended for something else. It doesn't completely mesh with the jcmd 
usage and other options, and the documentation story is quite complicated.

> This change can help avoid the need for an additional copy and paste step, 
> which is prone to errors.

To me that is not a sufficient benefit for the complexity this change would 
add. Further, it is not at all clear to me that a dynamic heap-dump _should_ be 
using the same destination as that set for the  `HeapDumpOnOutOfMemory` case.

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

PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-2024127213

Reply via email to