On Wed, 10 Apr 2024 13:03:40 GMT, Matthias Baesken wrote:
> > One other thing I just realized is that if we go through with this change,
> > then we can't in the future change VM.heap_dump so it can be used without
> > any filename (make it use a default filename when no filename is
> >
On Wed, 10 Apr 2024 04:34:53 GMT, Chris Plummer wrote:
> One other thing I just realized is that if we go through with this change,
> then we can't in the future change VM.heap_dump so it can be used without any
> filename (make it use a default filename when no filename is specified).
>
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Mon, 8 Apr 2024 06:47:09 GMT, Matthias Baesken wrote:
> If (3) has defaults, why (4) and (maybe) (5) don't have the same defaults?
I could open a separate JBS issue (or issues) for scenario 4 and 5 , if this is
desired.
-
PR Comment:
On Fri, 5 Apr 2024 22:47:55 GMT, Alex Menkov wrote:
> I don't have strong opinion if it's good to have default file path for `jcmd
> GC.heap_dump`, just some thoughts. We have several ways to heap dump:
>
> 1. `-XX:+HeapDumpOnOutOfMemoryError`
> 2. `-XX:+HeapDumpBeforeFullGC`,
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Fri, 5 Apr 2024 12:49:53 GMT, Sandra Payne 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
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Fri, 5 Apr 2024 08:57:09 GMT, Sandra Payne wrote:
> 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.
With this
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Wed, 3 Apr 2024 13:37:56 GMT, Christoph Langer wrote:
> Couldn't we just have an unconditional default for the GC.heap_dump
> `filename` option? This would simplify the documentation. E.g. we could write
> `If not specified, defaults to java_pid.hprof in the working directory
> or value
On Wed, 3 Apr 2024 09:04:34 GMT, Matthias Baesken wrote:
> > There's still the question of whether or not it is even appropriate to have
> > -XX options taking the place of jcmd options.
>
> Some people (like our cloud support colleagues and also some who commented)
> would like this
On Wed, 3 Apr 2024 08:03:22 GMT, Matthias Baesken wrote:
> > There's also a question of whether currently missing doc updates for
> > HeapDumpGzipLevel should be made part of this PR
> > because it complicates back porting.
>
> It should most likely be a separate PR (the title of this one does
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Fri, 29 Mar 2024 04:15:24 GMT, Chris Plummer wrote:
> There's still the question of whether or not it is even appropriate to have
> -XX options taking the place of jcmd options.
Some people (like our cloud support colleagues and also some who commented)
would like this approach, some find
On Fri, 29 Mar 2024 04:15:24 GMT, Chris Plummer wrote:
> There's also a question of whether currently missing doc updates for
> HeapDumpGzipLevel should be made part of this PR
> because it complicates back porting.
It should most likely be a separate PR (the title of this one does not match,
On Thu, 28 Mar 2024 15:08:27 GMT, Matthias Baesken wrote:
> Yes it is some work on documentation (but seems some doc work needs to be
> done anyway because it was forgotten when `HeapDumpGzipLevel` was introduced).
That currently only impacts 3 documents. Having HeapDumpGzipLevel apply to the
On Thu, 28 Mar 2024 15:08:27 GMT, Matthias Baesken wrote:
> Wouldn't this just be a case of changing a flag description? As luck has it,
> the flag already has a generic name that is not tied to OOMs.
One of the issues with this PR is that there are 7 places where some sort of
doc/help update
On Thu, 28 Mar 2024 07:02:16 GMT, Thomas Stuefe wrote:
> Wouldn't this just be a case of changing a flag description? As luck has it,
> the flag already has a generic name that is not tied to OOMs.
Yes it is some work on documentation (but seems some doc work needs to be done
anyway because
On Wed, 27 Mar 2024 23:33:18 GMT, Chris Plummer wrote:
> I did get feedback from a couple of our support engineers. One felt it was of
> no real benefit as it was just as easy to provide the > filename as an
> argument to the jcmd.
That might be true for this support engineer, but not for
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
On Wed, 27 Mar 2024 23:05:22 GMT, David Holmes wrote:
> Notwithstanding that there may be cases where this change would be
> convenient...
I did get feedback from a couple of our support engineers. One felt it was of
no real benefit as it was just as easy to provide the filename as an
On Wed, 27 Mar 2024 13:44:42 GMT, Matthias Baesken wrote:
>> Currently jcmd command GC.heap_dump only works with an additionally provided
>> file name.
>> Syntax : GC.heap_dump [options]
>>
>> In case the JVM has the XX - flag HeapDumpPath set, we should support an
>> additional mode where
> Currently jcmd command GC.heap_dump only works with an additionally provided
> file name.
> Syntax : GC.heap_dump [options]
>
> In case the JVM has the XX - flag HeapDumpPath set, we should support an
> additional mode where the is optional.
> In case the filename is NOT set, we take the
24 matches
Mail list logo
