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 23:26:14 GMT, Chris Plummer wrote:
>
> Backporting also came to mind since the trouble shooting guide would need to
> be updated for each Oracle version this PR is backported to. And yes,
> HeapDumpGzipLevel docs need to match the actual implementation. I'm not sure
> if
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 12:36:31 GMT, Matthias Baesken wrote:
> Sorry maybe it is maybe obvious for you but where should I open a "docs CR",
> would that be a separate JBS issue with Component name docs ?
You would file a JBS issue with component "docs" and subcategory "hotspot". But
let's hold
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
On Tue, 26 Mar 2024 21:42:15 GMT, Chris Plummer wrote:
> A docs CR will need to be filed to get it updated (and I see it is already
> appears out-of-date w.r.t. HeapDumpGzipLevel)
Sorry maybe it is maybe obvious for you but where should I open a "docs CR",
would that be a separate JBS issue
On Tue, 26 Mar 2024 13:57:55 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
On Fri, 15 Mar 2024 11:24:53 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, 15 Mar 2024 11:24:53 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 Thu, 21 Mar 2024 16:44:29 GMT, Chris Plummer wrote:
> I'd like to consult with a couple of people at Oracle who unfortunately are
> out of town until Monday. Can this PR wait until next week?
That's fine, no need to rush it into jdk-head this week.
-
PR Comment:
On Thu, 21 Mar 2024 16:32:09 GMT, Matthias Baesken wrote:
> 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 .
I'm still
On Fri, 15 Mar 2024 11:24:53 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 Tue, 19 Mar 2024 20:15:18 GMT, Chris Plummer 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
On Tue, 19 Mar 2024 10:16:42 GMT, Matthias Baesken wrote:
>>> If -XX:HeapDumpPath is specified, then it is used as the default
>>
>> No, the filename set with jcmd GC:heamp_dump filename has priority. So we
>> should better keep the current description.
>
> So should I also use
On Tue, 19 Mar 2024 10:13:16 GMT, Matthias Baesken wrote:
>> So far we only use the gzip level setting from jcmd, not HeapDumpGzipLevel .
>> See the `level` variable in `HeapDumpDCmd::execute` . Yeah you are probably
>> right we should make it consistent.
>
>> If -XX:HeapDumpPath is specified,
On Sat, 16 Mar 2024 12:50:05 GMT, Matthias Baesken wrote:
>> src/hotspot/share/services/diagnosticCommand.cpp line 475:
>>
>>> 473: HeapDumpDCmd::HeapDumpDCmd(outputStream* output, bool heap) :
>>> 474:DCmdWithParser(output, heap),
>>> 475:
On Fri, 15 Mar 2024 11:24:53 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, 15 Mar 2024 09:01:20 GMT, Matthias Baesken wrote:
> Hi Chris, thanks for the comments-
>
> > Also, if you are cleaning up this text, I would suggest changing "is on" to
> > "is enabled". Same for HeapDumpGzipLevel below.
>
> I changed the two locations. btw. seems we have more of
On Fri, 15 Mar 2024 11:24:53 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, 15 Mar 2024 19:22:58 GMT, Chris Plummer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> Adjust jcmd manpage, help and globals comment
>
> src/hotspot/share/services/diagnosticCommand.cpp line 475:
>
> 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
On Fri, 15 Mar 2024 06:59:42 GMT, Christoph Langer wrote:
>> src/hotspot/share/runtime/globals.hpp line 565:
>>
>>> 563: "triggered by jcmd GC.heap_dump without specifying a path, "
>>> \
>>> 564: "the path (filename or directory) of the dump file "
>>> \
> 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
On Fri, 15 Mar 2024 08:35:56 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, 15 Mar 2024 08:00:50 GMT, Yi Yang wrote:
> Maybe `dump` and `dump_to`
Why not, I renamed the method to dump_to .
-
PR Comment: https://git.openjdk.org/jdk/pull/18190#issuecomment-1999165924
> 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
> 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
On Thu, 14 Mar 2024 08:49:45 GMT, Matthias Baesken wrote:
> > Looks reasonable, this is a harmless change, but the name
> > `dump_to_heapdump_path` looks too details(and somewhat strange) to me
>
> Do you maybe have a good suggestion for a new name ?
Maybe `dump` and `dump_to`
-
On Thu, 14 Mar 2024 13:43:09 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 Thu, 14 Mar 2024 16:54:48 GMT, Chris Plummer wrote:
>> Matthias Baesken has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> add test HeapDumpJcmdPresetPathTest
>
> src/hotspot/share/runtime/globals.hpp line 565:
>
>> 563:
On Thu, 14 Mar 2024 13:43:09 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 Thu, 14 Mar 2024 13:43:09 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 Thu, 14 Mar 2024 13:43:09 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
On Thu, 14 Mar 2024 09:13:03 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
On Thu, 14 Mar 2024 02:39:28 GMT, Yi Yang wrote:
> Looks reasonable, this is a harmless change, but the name
> `dump_to_heapdump_path` looks too details(and somewhat strange) to me
Do you maybe have a good suggestion for a new name ?
-
PR Comment:
On Tue, 12 Mar 2024 12:22:41 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 Tue, 12 Mar 2024 08:23:04 GMT, Stefan Karlsson wrote:
> > GC folk should be reviewing this not runtime.
>
> I don't fully agree with that. How these serviceability tools work, and their
> interfaces, are usually not something that we GC devs are directly
> responsible for. This change
On Tue, 12 Mar 2024 13:27:13 GMT, Kevin Walls wrote:
>That's not necessarily wrong, and may not be serious enough to refuse
>-overwrite when using HeapDumpPath, but we want to
>find a way of making things clear (I was not going to suggest separate
>sequence numbers... 8-) )
Thanks for
On Tue, 12 Mar 2024 12:12:05 GMT, Matthias Baesken wrote:
> > jcmd GC.heap_dump has the overwrite flag.
> > OOM dumping in HeapDumper::dump_heap(bool oome) has a sequence number.
>
> There is (with this patch) still just one sequence number and it is
> incremented by all invocations of
On Tue, 12 Mar 2024 12:36:38 GMT, Matthias Baesken wrote:
> The path is already printed, here is an example (the JVM with pid 219447 was
> started with`-XX:HeapDumpPath=... `).
yes of course, when the new method calls dump(), thanks.
-
PR Comment:
On Tue, 12 Mar 2024 11:08:01 GMT, Kevin Walls wrote:
>Does dump_to_heapdump_path() not print the ("Dumping heap to %s ...", path)
>message?
>That seems important when the user isn't specifying it directly.
The path is already printed, here is an example (the JVM with pid 219447 was
started
> 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
On Tue, 12 Mar 2024 11:08:01 GMT, Kevin Walls wrote:
>jcmd GC.heap_dump has the overwrite flag.
>OOM dumping in HeapDumper::dump_heap(bool oome) has a sequence number.
There is (with this patch) still just one sequence number and it is incremented
by all invocations of
On Mon, 11 Mar 2024 11:57:04 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 the is
On Mon, 11 Mar 2024 11:57:04 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 the is
On Tue, 12 Mar 2024 06:15:20 GMT, David Holmes wrote:
> GC folk should be reviewing this not runtime.
I don't fully agree with that. How these serviceability tools work, and their
interfaces, are usually not something that we GC devs are directly responsible
for. This change could be reviewed
On Mon, 11 Mar 2024 11:57:04 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 the is
71 matches
Mail list logo
