RFR: JDK-8177763: Getting an hprof dump via jcmd could benefit from stronger option checking
Chris Plummer
chris.plummer at oracle.com
Wed Aug 29 18:04:23 UTC 2018
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/
>>>>
>>>>
>>>
>>
>>
>
More information about the serviceability-dev
mailing list