Hi Gary,
Ok. Overall looks good. A couple of comments:
You now output the path of the created file, but in a kind of strange
way. You print the CWD, and then the specified path, whether relative or
full. So it's kind of confusing because if the user specifies a full
path, they'll still see the CWD printed out. Why not just print the full
path (after combining with CWD if needed), or maybe omit the CWD off
when a full path was specified. If determining if CWD ends up getting
used is difficult, maybe just make it more clear what you are printing
is the CWD, and it is not necessarily part of the actual filename path.
What about writing some tests cases. It would probably be pretty easy to
update some of the existing test cases to use key=<value> where
previously they just allowed <value>.
thanks,
Chris
On 8/29/18 8:10 AM, Gary Adams wrote:
Sure no problem.
I have two workspaces I use called jdk-jdb and jdk-jdk.
I have the changes in the jdk-jdb workspace for the heap
filename updates.
In the jdk-jdb workspace a launch a process that just waits for input.
jdk/bin/java -cp ~/classes my
In the jdk-jdk workspace I issue the jcmd to talk to the java process
running in the jdk-jdb workspace. The updated output includes
"[<current-directory>,<heap dump filename>]"
...
$ jdk/bin/jcmd 2328 GC.heap_dump filename=foo
2328:
Heap dump file created
[/export/users/gradams/ws/jdk-jdb/build/linux-x64,foo]
$ jdk/bin/jcmd 2328 GC.heap_dump filename
2328:
Heap dump file created
[/export/users/gradams/ws/jdk-jdb/build/linux-x64,filename]
$ jdk/bin/jcmd 2328 GC.heap_dump ffoo2
2328:
Heap dump file created
[/export/users/gradams/ws/jdk-jdb/build/linux-x64,ffoo2]
$ jdk/bin/jcmd 2328 GC.heap_dump ffoo2
2328:
File exists [/export/users/gradams/ws/jdk-jdb/build/linux-x64,ffoo2]
$ jdk/bin/jcmd 2328 GC.heap_dump ~/ffoo2
2328:
Heap dump file created
[/export/users/gradams/ws/jdk-jdb/build/linux-x64,/home/gradams/ffoo2]
$ jdk/bin/jcmd 2328 GC.heap_dump ~/ffoo2
2328:
File exists
[/export/users/gradams/ws/jdk-jdb/build/linux-x64,/home/gradams/ffoo2]
$ jdk/bin/jcmd 2328 GC.heap_dump /tmp/ffoo2
2328:
Heap dump file created
[/export/users/gradams/ws/jdk-jdb/build/linux-x64,/tmp/ffoo2]
$ jdk/bin/jcmd 2328 GC.heap_dump /tmp/ffoo2
2328:
File exists [/export/users/gradams/ws/jdk-jdb/build/linux-x64,/tmp/ffoo2]
$ pwd
/home/gradams/scratch/ws/jdk-jdk/build/linux-x64
On 8/29/18, 2:21 AM, Chris Plummer wrote:
Hi Gary,
What would be really useful are some before/after examples that
demonstrate what has changed from the users point of view.
thanks,
Chris
On 8/28/18 5:26 AM, Gary Adams wrote:
This message may have been lost in the vacation email backlog, so I'm
sending it again.
On 8/9/18, 2:19 PM, Gary Adams wrote:
Thee are several reported problems using jcmd for obtaining heap
dumps.
Some users are confused by the positional argument for a filename
when a similar jfr command uses "key=value" syntax.
Some users are confused by the basic nature of the command, where
the jvm
executing the heap dump is running in a different current directory
than
the jcmd itself.
This is a proposed fix to report the current directory and the
filename
when the heap dump is successfully written or if an error occurs.
There
is also a proposed fix to handle the case when the user provided
"key=value" inputs. If the key matches the argument name, then the
user intended the value to be used.
Issue: https://bugs.openjdk.java.net/browse/JDK-8177763
Webrev: http://cr.openjdk.java.net/~gadams/8177763/webrev.00/
