RFR: 8275259: Add support for Java level DCmd
Ioi Lam
ioi.lam at oracle.com
Tue Nov 9 22:54:37 UTC 2021
On 11/9/21 2:07 PM, Chris Plummer wrote:
> 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.holmes at 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.
>
Is there anything in the proposal that cannot be done by JMX? If the app
wants to provide a hook to expose some of its internals to be
monitored/controlled by an external tool, maybe it can just implement a
new MBean?
Granted, it's bit more tedious to connect to JMX than using "jcmd".
However, much of that is for security. If we allow an app to implement
new jcmd handlers using Java code, we have to think about the whole
security model again. Are we reinventing the wheel here?
Thanks
- Ioi
More information about the serviceability-dev
mailing list