Hi all,
I had an offline discussion about this with Denghui, when I first time
hear this idea, I felt it was useful. It allows users to do some stuff
that requires a lot of effort in a simple way. I'm also tracking
discussion on the mailing list, I've seen many folks come up with very
constructive comments and questions/concerns. In order to make the
follow-up discussion simple, I want to try to summarize and give some
answers on behalf of myself. Each headline is a question/concern that
folks are concerned about, followed by my personal opinion on it. I'd
appreciate it if you can append any missing content.
=== What is it?
It provides the ability for users to trigger predefined callbacks
while the application is running.
=== May misuse?
It is provided through jcmd, this ability should ideally be used for
debugging/development/diagnosis purposes. It may be misused, but this
is beyond our control, just as users can use signal handler to
download App and play a song.
=== Maintainability?
It expands current jcmd implementation rather than a significant
modification, so maintainability should be ok IMHO.
=== Safety?
Undeniably, it may raise some potential security issues.
=== Alternatives?
Socket: It is inconvenient for users to simply do the same thing
compared to this, we have to write a lot of boilerplate socket code.
Signal: Not open to users, a limited number of signals, more likely
to be misused.
=== Purpose?
1. I have a web application that can analyze Java heap dump. I hope to
provide a simple way to report runtime app metrics, such as disk usage
and online worker load, instead of writing a complete web page and
providing an admin page to access it. This information can also be
gathered on other monitoring platforms.
2. Trigger the DEBUG functionality while running, output some debug logs
Best regards.
------------------------------------------------------------------
From:Chris Plummer <chris.plum...@oracle.com>
Send Time:2021 Nov. 4 (Thu.) 14:10
To:dong denghui <denghui....@alibaba-inc.com>; serviceability-dev
<serviceability-dev@openjdk.java.net>; hotspot-dev
<hotspot-...@openjdk.java.net>
Subject:Re: [External] : Re: RFC: Extend DCmd(Diagnostic-Command)
framework to support Java level DCmd
Hi Denghui,
Yes, there are other ways the same thing could be accomplished
like sockets or signals, but all of this is outside of the purview
of the JDK, and therefore we don't become responsible for its
design, maintenance, and potential security concerns.
EnableUserLevelDCmd doesn't really fix any of these concerns,
because an app can just always launch with this flag enabled. It
really should be reserved for launching a JVM for the specific
purpose of gathering some extra diagnostic data, but there is no
way to enforce that.
Anyway, I'm not the gatekeeper on this. Just expressing some of my
concerns. Others have done the same. I think we've seen a lack of
enthusiasm in favor of doing this except from you. I would be good
to see input from others that would like this feature in place.
cheers,
Chris
On 11/1/21 8:09 PM, Denghui Dong wrote:
Hi Chris,
Thank you for the comments.
Yes, we have no good way to restrict the user registration commands to only
include diagnosis-related operations, but in my opinion, this does not seem to
be a problem that must be solved perfectly.
The following are my thoughts.
This extension is an entry that triggers the operation that the user wants
to perform (similar to the Signal Handler mechanism but with a name and
parameters). Even without this extension, the user can have other ways to
achieve the same goal.
On the one hand, we could standardize the usage scenarios of the API on the
document(Indeed, users can still write programs not in accordance with the
specifications, for example, users can implement multiple calls to the same
object's hachCode method to return different values or make an object alive
again during finalize method executing).
On the other hand, we can add some restrictions to help users make better
use of this extension.
e.g we can add a new VM option, such as EnableUserLevelDCmd, the
application can only register customer commands when this option is enabled.
Or from another perspective, can we allow users to do some
non-diagnostic-related operations in custom commands?
Best,
Denghui
------------------------------------------------------------------
From:Chris Plummer <chris.plum...@oracle.com>
Send Time:2021年11月2日(星期二) 03:35
To:董登辉(卓昂) <denghui....@alibaba-inc.com>; serviceability-dev
<serviceability-dev@openjdk.java.net>; hotspot-dev
<hotspot-...@openjdk.java.net>
Subject:Re: RFC: Extend DCmd(Diagnostic-Command) framework to
support Java level DCmd
I have similar concerns to those others have expressed, so I'll
try to add something new to the discussion and not just repeat.
DCMDs have historically been very VM centric. That's not to say
they aren't useful for debugging applications, but they do so by
providing VM related info like stack traces, heap dumps, and class
histograms. Also hotspot has been the gatekeeper for new DCMDs,
meaning that new ones do not get added without going through the
hotspot review process.
Allowing any application or framework to add a DCMD changes this
VM centric view in a way that concerns me. This approach allows a
DCMD to pretty much do anything (java security not withstanding).
App writers could even use them to provide a user facing
interface. For example, if an app has some sort internal database,
it could allow users to query it via a DCMD, and maybe even
suggest that users write simple shell scripts that use jcmd to do
these queries. Allowing this type of non-diagnostic usage seems
like a path we don't want to go down, yet I don't see how it can
be prevented once you allow applications to add DCMDs.
Chris
On 10/25/21 1:37 AM, Denghui Dong wrote:
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) {
System.out.println("...");
}
```
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!
Thanks,
Denghui
