RFC: Extend DCmd(Diagnostic-Command) framework to support Java level DCmd

Denghui Dong denghui.ddh at alibaba-inc.com
Mon Oct 25 08:37:07 UTC 2021

Hi there!

We'd like to discuss a proposal for extending the current DCmd framework to support Java level DCmd.

At present, DCmd only allows the VM to register commands, which can be called through jcmd or JMX. It would be beneficial if the user could create their own commands.

The idea of this extension originally came from our internal Java agent that detects the misusage of Unsafe API.

This agent can collect the call sites that allocate or free direct memory in the application(NMT could not do it IMO) to detect direct memory leaks.

In the beginning, it just prints all call sites, without any statistical function, it's hard to use.

So we plan to use a way similar to jeprof (from jemalloc) to generate a report file that aggregates all useful information.

During the implementation process, we found that we need a mechanism to notify the agent to generate reports.

The common practice is:
a) Register a service port, triggered by an HTTP request
b) Triggered by signal
c) Generate reports periodically, or when the process exits

But these three ways have certain problems.
For a) we need to introduce a network component, will increase the complexity of implementation
For b) we cannot pass parameters
For c) some files that may never be used will be generated

Essentially, this question is how to notify the application to do a certain task, or in other words, how do we issue a command to the application. We believe that other Java developers will also encounter similar problems. 
(And sometimes there may be multiple unrelated dependent components in a Java application that require such a mechanism.)

Naturally, we think that jcmd can already issue some commands registered in VM to the application, why can't we extend to the java level?

This feature will be very useful for some lightweight tools, just like the scenario we encountered, to notify the tools to perform certain operations.

In addition, this feature will also bring benefits to Java beginners.

For example, in the beginning, beginners may not use advanced log components, but they will also encounter the need to output debug logs. They may write code like this:

    if (debug) {

If developers can easily control the value of debug, it's attractive.

Like this:

    Factory.register("MyApp.flipDebug", out -> debug = !debug);

    jcmd <pid> MyApp.flipDebug

For mainstream framework, we can apply this feature to trigger some common activities, such as health checks, graceful shutdown, and dynamic configuration updates, But to be honest, these frameworks are very mature and stable, and for compatibility purposes, it's hard to let them use this extension.

Comments welcome!

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20211025/9e2a815c/attachment.htm>

More information about the serviceability-dev mailing list