RFR: 8275259: Add support for Java level DCmd

[Denghui Dong]

On Thu, 14 Oct 2021 05:42:09 GMT, Denghui Dong <ddong at openjdk.org> wrote:

> I proposed to extend DCmd to allow Java developers to customize their own diagnostic commands last week.
> 
> At present, I have implemented a preliminary version.
> 
> In the current implementation, I provided some simple APIs in the Java layer (under sun.management.cmd) for defining and registering commands.
> 
> - Executable interface
>   Java diagnostic commands need to implement this interface, the interface only contains a simple method:
> 
>     /**
>      * @param output the output when this executable is running
>      */
>     void execute(PrintWriter output);
> 
> 
> - Add two annotations (@Command and @Parameter) to describe the command meta info
> 
> - Use Factory API to register command, the following forms are supported
> 
> @Command(name = "My.Echo", description = "Echo description")
> class Echo implements Executable {
> 
>     @Parameter(name = "text", ordinal=0, isMandatory = true)
>     String text;
> 
>     @Parameter(name = "repeat", isMandatory = true, defaultValue = "1")
>     int repeat;
> 
>     @Override
>     public void execute(PrintWriter out) {
>         for (int i = 0 ; i < repeat; i++) {
>             out.println(text);
>         }
>     }
> }
> 
> Factory.register(Echo.class);
> 
> 
> 
> Factory.register("My.Date", output -> {
>     output.println(new Date());
> });
> 
> 
> - When the command is running, the VM will call `Executor.executeCommand` to execute the command. In the implementation of Executor, I introduced a simple timeout mechanism to prevent the command channel from being blocked.
> 
> At the VM layer, I extended the existing DCmd framework(implemented JavaDCmd and JavaDCmdFactoryImpl) to be compatible with existing functions (jmx, help, etc.).
> 
> In terms of security, considering that the SecurityManager will be deprecated, there are not too many considerations for the time being.
> 
> Any input is appreciated.
> 
> Thanks,
> Denghui

Hi Thomas,

> Hi,
> 
> Interesting proposal. I have some questions.
> 
> * Will hanging java user code block the attach listener thread? If yes, how would you solve that?

In my current implementation, I use a simple timeout mechanism to solve this problem.

Create a Thread to run the command, and use `java.util.concurrent.Future#get(long, java.util.concurrent.TimeUnit)` to get the result.

For more details please refer to Executor.java.


> * Will this require changes to the jcmd client, or will this work with any jcmd client, up- and downward the JDK versions? (the nice thing about jcmd is that all the logic resides at the hotspot and I can use any client to talk to any hotspot)
> 

At present, I only extend the DCMD framework and do not modify the code of jcmd. So it works with any jcmd client and jmx client, up and downward JDK versions I think.

> Cheers, Thomas
> 
> P.S. I think it may be worthwhile to discuss this on the serviceability-dev mailing list first.

Denghui

Hi Erik,
> To understand what is needed (namespacing, error handling, safety, lifecycle etc.) and if this is actually useful for Java, I think you need to write 2-3 commands for a few popular frameworks, for example Spring.
> 
> If we can't come up with 5-10 commands where this functionality would solve real problems users face, it's unlikely somebody will use it. It will just be a maintenance burden in the JDK. Once an API is added, it's hard to remove.
> 
> The scope of this seem to be JEP level.
> 
> (JFR is not a valid use case, since we don't want to add a dependency on annotation classes in the jdk.jcmd module).

Thanks for the comments.

I will investigate whether there is a scenario to apply this extension in the current mainstream framework.

Denghui

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

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