Extend jcmd to java application level

[Erik Gahlin]

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.lam at oracle.com>
Send Time:2021 Oct. 8 (Fri.) 15:22
To:David Holmes <david.holmes at oracle.com>; dong denghui <denghui.ddh at alibaba-inc.com>; serviceability-dev <serviceability-dev at openjdk.java.net>; hotspot-runtime-dev at openjdk.java.net <hotspot-runtime-dev at 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