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

[Christoph Langer]

On Fri, 5 Apr 2024 12:49:53 GMT, Sandra Payne <duke at openjdk.org> wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust java.1 man page
>
> Yes, exactly the latter.  With this change, it opens the door for the above scenario to unwittingly occur, either through user error (simple omission of a previously used parameter)  or lack of understanding of the impact not using the parameter will have.

Hi @spayne8,

thanks for your elaborate answer. Let me comment on your points:
 
> I disagree with the premise of this entire request that jcmd GC.heap_dump should follow -XX:HeapDumpPath. Many customers may see such a change as a regression, as they rely on separation of location for heap dumps generated by the JVM at OOME and heap dumps manually pulled by various other processes attaching to the JVM.

I at least can't see the regression here, because it's still possible to separate the locations of automatic and manual heap dumps by setting a value to the jcmd call.

> Regarding this justification:
> 
> > 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.
> 
> It's too weak an argument to justify such a change. Simple scripts can capture and propagate the HeapDumpPath value, if you really want to go that route.

Sure but we want to avoid that need and have it more comfortable without having to write scripts.

> However, I recommend using separate directories for manual heap dumps. Keeping them separate from JVM-initiated heap dumps, either through filename convention or separate directories, is a best practice. When you have a severity 1 down situation due to OOME crashes, you don't want to have a bunch of manually pulled heap dumps cluttering up your view of the JVM initiated ones. You want to be able to get your hands on the exact heap dumps you need very quickly to have them analyzed for root cause.

Sure, but the change requested here does not go against that best practice. You still can have different location for manual heap dumps and the file systems should probably cleaned up from old heap dumps anyway.

> For this reason I also disagree with setting a default filename convention equivalent to the default HeapDumpPath filename. Manual heap dumps require specifying a filename for a reason, and those filenames (and separate directories for those who define them) should be unique based on what triggered the heap dump. Consider the numerous Support cases of multiple monitoring scripts kicking off jcmd processes to pull heap dumps at various resource usage thresholds, as well as multiple Java agents that may do so, e.g. for various performance reasons.

Well, I guess, after all it's a bit of a matter of taste. I personally would think having a default for hprof files obtained by jcmd should provide some kind of comfort. Maybe/probably that default should be different from the one for the JVM initiated automatic heapdumps but still it would be helpful if it could be configured, maybe by another XX option.

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

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