On Tue, 19 Mar 2024 20:15:18 GMT, Chris Plummer <cjplum...@openjdk.org> wrote:
>> So should I also use HeapDumpGzipLevel the same way as HeapDumpPath ? Tehn >> we have to change the text in globals.hpp for HeapDumpGzipLevel as well >> because it mentions only the HeapDumpOnOutOfmemoryError case and not the >> jcmd case . > > I actually mentioned HeapDumpGzipLevel as another reason not to make this > change. I'm still not seeing it's value relative to the documentation > headaches it causes. > > @ansteiner commented that: > >> This is really helpful from a support point of view. > > I'd like to understand how. It seems to me that the person using the jcmd has > a lot more interest in where the file ends up than the person launching the > JVM, and can always specify the location with the jcmd. It seems odd to me > that the jcmd user would want to rely on HeapDumpPath when they can just > specify the path with the jcmd and know for sure where the file is going to > end up. 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18190#discussion_r1531715298
