RFR: JDK-8187498: Add a -Xmanagement flag as syntactic sugar for -Dcom.sun.management.jmxremote.* properties

[Harsha Wardhana B]

Ping. Could I please have reviews for below webrev.

Thanks
Harsha

On Wednesday 14 February 2018 09:59 PM, Harsha Wardhana B wrote:
> Hi,
>
> Below is the updated webrev.
>
> http://cr.openjdk.java.net/~hb/8187498/webrev.03/
>
>
> On Wednesday 14 February 2018 01:15 AM, mandy chung wrote:
>>
>>
>> On 2/13/18 1:30 AM, Harsha Wardhana B wrote:
>>> Hi,
>>>
>>> Please find below the revised webrev.
>>>
>>> http://cr.openjdk.java.net/~hb/8187498/webrev.02/
>>>
>>>
>>> On Friday 09 February 2018 05:07 AM, mandy chung wrote:
>>>> On 2/7/18 1:19 AM, Harsha Wardhana B wrote:
>>>> > 
>>>> > --start-management-agent will not be recognized in the current format and
>>>> > hence will not default to --start-management-agent=local=true.
>>>>
>>>> `--start-local-management-server` is one option as Alan suggests.
>>>> Another option is to make `--start-management-agent` to accept
>>>> an optional argument.  VM can accept `--start-management-agent`
>>>> or `--start-management-agent=port=1234,ssl=on`.  It may require
>>>> more launcher change to support it.
>>> Yes. It requires lot more changes to launcher. Hence optional 
>>> argument to --start-management-agent was not added in order to keep 
>>> the launcher impact minimum.
>>
>> This is just one option for you to consider.   So the current 
>> proposal of the new option to start a remote management server, right?
> Not necessarily. --start-management-agent=local=true starts local 
> server and --start-management-agent=port=1234 starts remote management 
> server.
>>>> Agent.java
>>>>   If --start-management-agent is set, -Dcom.sun.management.* takes
>>>>   precedence.  Do you really want to do that?  The new VM option
>>>>   intends to simplify the command-line to type in.  I think it's
>>>>   cleaner and reasonable if --start-management-agent is specified,
>>>>   -Dcom.sun.management.* are ignored (maybe worth emit a warning if set)
>>> We can probably document that -D options will be overridden instead 
>>> of emitting a warning.
>>
>> What is the behavior when -Dcom.sun.management.jmxremote.port=1234 
>> --start-management-agent port=2345 
>> -Dcom.sun.management.jmxremote.port=3456?
>>
>> What is the value of the system property 
>> com.sun.management.jmxremote.port at runtime?  What port number does 
>> the management server start with?
> As said earlier, values set via new flags override values set by -D 
> flags. So 2345 will be the value of com.sun.management.jmxremote.port. 
> Added a test case to validate that.
>>
>>>>   The implementation uses VMManagement::getVmArguments and scan
>>>>   the VM options for -start-management-agent.  The VM is the one
>>>>   invoking jdk.internal.agent.Agent::startAgent.  A simpler option
>>>>   is to change Agent::startAgent to take an argument parameter
>>>>   that will be passed with the argument of --start-management-agent
>>>>   or null if not set.
>>>>
>>>>   Similarly for startRemoteManagementAgent and startLocalAgent_name.
>>> Implementing this change requires lot of changes to argument parsing 
>>> in native code and hence it is simpler to handle this at java layer.
>>
>> Can you describe how --start-management-agent option will be used for 
>> jcmd and any other tool that attaches to a running VM to start the 
>> agent?  Example command-line will be useful.
> --start-management-agent cannot be used by jcmd (or dynamic attach) as 
> it accepts flags only in -D format or -D flags with com.sun.management 
> removed. That code to parse string passed via jcmd was a mistake and 
> hence I have removed it.
>>
>>
>> Mandy
> -Harsha