To make an application command usable, it must provide metadata (name and
description of the command, its options’ data types, units, default values, if
it is mandatory etc.) and error handling. This will make the API surface larger
and trickier to get right.
(Not a full overlap, but we are thinking of adding more interactive
capabilities to JFR now that we have event streaming. The design hasn’t
started, but one could imagine a command to see object allocation events
aggregated in a histogram. Such a command may be able to operate on
user-defined events as well, including requestable/periodic events.)
Erik
That seems an ideal solution. I think there are some potential code
consolidation work further. With this change, some existing C++ JFR Jcmd
structure definitions(and other Jcmd commands) in VM level can also be lifted
to Java level because they simply forward request to Java level by
JavaCalls::call_static.
------------------------------------------------------------------
From:Ioi Lam <ioi....@oracle.com>
Send Time:2021 Oct. 8 (Fri.) 15:22
To:David Holmes <david.hol...@oracle.com>; dong denghui
<denghui....@alibaba-inc.com>; serviceability-dev
<serviceability-dev@openjdk.java.net>; hotspot-runtime-...@openjdk.java.net
<hotspot-runtime-...@openjdk.java.net>
Subject:Re: Extend jcmd to java application level
On 10/7/21 6:25 PM, David Holmes wrote:
> Hi Denghui,
>
> On 7/10/2021 11:58 pm, Denghui Dong wrote:
>> Hi team,
>>
>> The `jcmd` command can be used to call some built-in diagnostic commands in
>> vm.
>>
>> Can we consider extending it to the java layer like perf data, so that Java
>> developers can
>>
>> customize their diagnostic commands and then call them through `jcmd`?
>>
>> One application scenario I can think of for this extension is that some
>> statistical information
>>
>> may be collected in a java application. Triggering the output of this
>> statistical information through
>>
>> the `jcmd` command seems to me relative to other mechanisms that trigger
>> output (such as through
>>
>> an HTTP service, or periodic Printing) is more convenient.
>>
>> Any input is appreciated.
>
> If the intent is that you could issue a jcmd:
>
> jcmd <vmid> MyClass.foo
>
> to have it run/use a Java thread to execute arbitrary code then I
> think a lot of careful consideration would need to be given to making
> this facility safe and secure. I can easily imagine that the thread
> used, and the timing, could cause failures. Executing arbitrary code
> may be far too general, so it might mean we need a new "service"
> interface defined that the target class has to implement.
>
> It might well be useful but will need some deep thought IMO.
>
If I understood correctly, the app would need to call an API like:
JcmdProvider.register("mycmd1", new JcmdHandler() {
public void handleCommand(String args[], PrintStream out) {
out.print("my response is ");
... }
});
and then the user can issue:
jcmd <pid> mycmd1 args .....
which will reach the handleCommand() method provided by the app.
Thanks
- Ioi
> Cheers,
> David
>
>> Thanks,
>> Denghui Dong
