Below is the updated webrev.


On Wednesday 14 February 2018 01:15 AM, mandy chung wrote:

On 2/13/18 1:30 AM, Harsha Wardhana B wrote:

Please find below the revised webrev.


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.
  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.


Reply via email to