[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: JDK-8177064: jcmd help command should not require the process identification
From:       David Holmes <david.holmes () oracle ! com>
Date:       2019-04-12 13:06:08
Message-ID: 06eb8f72-5a65-9a82-2aa7-f8147203c1ca () oracle ! com
[Download RAW message or body]

On 12/04/2019 9:47 pm, Gary Adams wrote:
> On 4/11/19, 8:16 PM, David Holmes wrote:
>> Hi Gary,
>>
>> On 12/04/2019 4:24 am, Gary Adams wrote:
>>> Two years ago a request was made to allow
>>>
>>>        jcmd help
>>>
>>> to be interpretted as a request for help from the current jcmd process
>>> rather than requiring a separate target process to be involved.
>>>
>>> Some attempts were made to close the issue, because the
>>> command was not documented to work that way.
>>> It was also pointed out that the help from the running jcmd
>>> might not match the cmds available from a subsequent
>>> request to a different process possibly running a different version
>>> of the vm.
>>>
>>> As proof of concept exercise this webrev shows a minimal set of
>>> changes that could support
>>>
>>>      jcmd self help
>>>
>>> Before fleshing out additional changes in documentation and testing,
>>> I'd like to know if this is still a worth while enhancement. Also,
>>
>> Given we allow a pid of 0 to mean all Java processes I can see scope 
>> for a special value that means "the current Java process", but using a 
>> text word like "self" seems awkward at best. Plus within a shell you 
>> can use: jcmd $$ help
> $$ is the pid for the shell where the command is running,
> not the jcmd pid.

Ooops. I thought there was a trick to pass the new process it's own pid 
as an arg.

> $ jcmd $$ help
> 17076:
> com.sun.tools.attach.AttachNotSupportedException: Unable to open socket 
> file: target process not responding or HotSpot VM not loaded
>         at 
> sun.tools.attach.BsdVirtualMachine.<init>(BsdVirtualMachine.java:90)
>         at 
> sun.tools.attach.BsdAttachProvider.attachVirtualMachine(BsdAttachProvider.java:63) 
> 
>         at com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:208)
>         at sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:147)
>         at sun.tools.jcmd.JCmd.main(JCmd.java:131)
> 
>>
>> to act on the jcmd VM itself, so there doesn't need to be special 
>> treatment in that sense. Perhaps some tweaks to the "jcmd -h" text.
> If we did allow the self attach, we would need to update the help text.
> I initially worked with -1 as another special value, but that looks a lot
> like -l the list argument.
> 
>>
>>> I'd like to know more about the history of the checks preventing self 
>>> attach.
>>
>> This may give you a start: 
>> https://bugs.openjdk.java.net/browse/JDK-8177154
> I understand the dangers of agent loading and the arguments against
> command line options and default settings that took place in jdk9
> release.
> 
> I'm looking for something older that explains the rationale about
> not allowing attach to the current process.

I'd suggest speaking to Alan or Mandy.

Cheers,
David

>>
>> Cheers,
>> David
>>
>>>      Webrev: http://cr.openjdk.java.net/~gadams/8177064/webrev/index.html
>>>      Issue: https://bugs.openjdk.java.net/browse/JDK-8177064
> 
[prev in list] [next in list] [prev in thread] [next in thread]