Re: Extend jcmd to java application level

[Denghui Dong]

Hi,

Thank you for the response.

I just made a PoC for this extension: 
https://github.com/D-D-H/jdk/commit/eb2a13b7ba8bd3e6d048491c8a579b179d2cef0d

Here is the test code:
```
import sun.management.cmd.CmdMeta;
import sun.management.cmd.Command;
import sun.management.cmd.ParamMeta;
import sun.management.cmd.Factory;

import java.io.PrintWriter;

public class Test {

  public static void main(String... args) throws Exception {
Factory.register(Echo.class);
Thread.sleep(6);
  }
}

@CmdMeta(name = "My.Echo")
class Echo implements Command {
public Echo() {}

@ParamMeta(name = "text", isMandatory = true)
String text;

@Override
public void execute(PrintWriter out) {
  out.println(text);
}
}
```
Verify steps:
1. javac --add-exports java.management/sun.management.cmd=ALL-UNNAMED Test.java
1. java --add-exports java.management/sun.management.cmd=ALL-UNNAMED Test
3. jcmd  My.Echo text=message

At present, it is only the most basic implementation, mainly referring to the 
implementation of dmcd in the VM layer. and there are many places that need 
more careful design and implementation, such as security and timeout

If you think this extension is useful, I'm happy to continue this work.

Thanks,
Denghui
--
From:董登辉(卓昂) 
Send Time:2021年10月7日(星期四) 21:58
To:serviceability-dev ; 
hotspot-runtime-...@openjdk.java.net 
Subject:Extend jcmd to java application level

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.

Thanks,
Denghui Dong

Re: 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 
Send Time:2021 Oct. 8 (Fri.) 15:22
To:David Holmes ; dong denghui 
; serviceability-dev 
; 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  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  mycmd1 args .

which will reach the handleCommand() method provided by the app.

Thanks
- Ioi






> Cheers,
> David
>
>> Thanks,
>> Denghui Dong

Re: Extend jcmd to java application level

[Yi Yang]

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 
Send Time:2021 Oct. 8 (Fri.) 15:22
To:David Holmes ; dong denghui 
; serviceability-dev 
; 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  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  mycmd1 args .

which will reach the handleCommand() method provided by the app.

Thanks
- Ioi






> Cheers,
> David
>
>> Thanks,
>> Denghui Dong

Re: Extend jcmd to java application level

[Ioi Lam]

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

which will reach the handleCommand() method provided by the app.

Thanks
- Ioi







Cheers,
David


Thanks,
Denghui Dong

Re: Extend jcmd to java application level

[Yasumasa Suenaga]

Hi Denghui,

I thought to add JMX client feature to jcmd in the past for similar purposes, 
but I didn't because JMX URL is too complex to type into console :)

Your proposal is useful, but it means malicious users can inject arbitrary 
code. I think we need to consider security, and existing framework like JMX 
might help us.


Thanks,

Yasumasa


On 2021/10/08 10:09, Denghui Dong wrote:

Hi Yasumasa,

JVMTI.data_dump and DataDumpRequest can achieve the purpose of triggering.

IIUC, DataDumpRequest does not seem to be able to pass parameters.
And sometimes the action the user wants to trigger may not be a data dump.

In fact, I think that commands such as JFR.start/stop are such a mechanism, 
triggered by `jcmd`, and finally callback to the java layer.

Denghui Dong

--
From:Yasumasa Suenaga 
Send Time:2021年10月8日(星期五) 07:45
To:董登辉(卓昂) ; serviceability-dev 
; hotspot-runtime-...@openjdk.java.net 

Subject:Re: Extend jcmd to java application level

Hi Denghui,


I think you can do it with combination of JVMTI.data_dump dcmd and 
DataDumpRequest event in JVMTI.

JVM(TM) Tool Interface 17.0.0 (oracle.com) 



Thanks,

Yasumasa


On 2021/10/07 22:58, 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.

Thanks,
Denghui Dong

Re: Extend jcmd to java application level

[David Holmes]

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

Cheers,
David


Thanks,
Denghui Dong

Re: Extend jcmd to java application level

[Denghui Dong]

Hi Yasumasa,

JVMTI.data_dump and DataDumpRequest can achieve the purpose of triggering.

IIUC, DataDumpRequest does not seem to be able to pass parameters.
And sometimes the action the user wants to trigger may not be a data dump.

In fact, I think that commands such as JFR.start/stop are such a mechanism, 
triggered by `jcmd`, and finally callback to the java layer.

Denghui Dong
--
From:Yasumasa Suenaga 
Send Time:2021年10月8日(星期五) 07:45
To:董登辉(卓昂) ; serviceability-dev 
; hotspot-runtime-...@openjdk.java.net 

Subject:Re: Extend jcmd to java application level

Hi Denghui,

I think you can do it with combination of JVMTI.data_dump dcmd and 
DataDumpRequest event in JVMTI.
JVM(TM) Tool Interface 17.0.0 (oracle.com)

Thanks,
Yasumasa

On 2021/10/07 22:58, 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.

Thanks,
Denghui Dong

Re: Extend jcmd to java application level

[Yasumasa Suenaga]

Hi Denghui,


I think you can do it with combination of JVMTI.data_dump dcmd and 
DataDumpRequest event in JVMTI.


JVM(TM) Tool Interface 17.0.0 (oracle.com) 




Thanks,

Yasumasa


On 2021/10/07 22:58, 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.

Thanks,
Denghui Dong