On 10/14/21 12:38 AM, David Holmes wrote:
On 14/10/2021 5:14 pm, Denghui Dong wrote:
On Thu, 14 Oct 2021 06:43:20 GMT, David Holmes <david.hol...@oracle.com> wrote:

I'm not sure exactly where this API would need to go. IIUC jcmd doesn't
exist at the Java level it is just a tool, so introducing an API to
interact with it seems problematic to me.

IMO, `jcmd` is a client of `dcmd`, the user also can use JMX to execute `dcmd`, this means there already are Java APIs interact with `dcmd`.

Ah right - so you're really looking at extending the capabilities of the DiagnosticCommandMBean to add a way to register a Java diagnostic command.

David

Just reviewing some previous emails and noticed this one since I recently looked into the JMX support. JMX supports a rather generic concept of executing diagnostics commands (there is no actual reference to "dcmds"). See com.sun.management.DiagnosticCommandMBean and its superinterface javax.management.DynamicMBean:

https://docs.oracle.com/en/java/javase/15/docs/api/jdk.management/com/sun/management/DiagnosticCommandMBean.html
https://docs.oracle.com/en/java/javase/15/docs/api/java.management/javax/management/DynamicMBean.html

DynamicMBean provides the invoke() interface, which when used on a DiagnosticCommandMBean will invoke the specified diagnostic command. It says nothing about how diagnostic commands are implemented or registered with the jvm. That I assume would be JVM implementation dependent.

Ah right - so you're really looking at extending the capabilities of the DiagnosticCommandMBean to add a way to register a Java diagnostic command.
Yes to "add a way to register a Java diagnostic command", but the new API will not involve DiagnosticCommandMBean in any way. The new API will interface with the existing hotspot native support for dcmds to allow dcmds to be implemented by and registered from java.

In any case, I think having an API that allows you to invoke a diagnostic command from java is very different in scope from an API that allows you to implement one in java, so I'm not so sure this JMX precedence serves us much purpose here.

Chris

Denghui

-------------

PR: https://git.openjdk.java.net/jdk/pull/5938


Reply via email to