|
It probably would not be that hard to
get SA to load a .class file and call some init function in it,
which in turn could register commands. There is already a
CommandProcessor.registerCommand() for adding _javascript_ commands.
It can easily be overloaded to add a version for registering
commands implemented in java. One thing I'm a bit unclear on is
how modules would play a role in this, and the ability for the
commands to access all the internal SA APIs, which I think they
would likely need.
Chris
On 12/10/19 9:39 PM, Krystal Mok wrote:
Hi Yasumasa,
That's a very nice idea. Basically what you're asking for
is exposing the Command interface [1] so that plugins can
implement it and get dynamically loaded / registered into
CLHSDB / HSDB, right?
- Kris
Hi
Chris,
It's a sad proposal, but I agree with you. To maintain SA in
JS is difficult since Jigsaw.
However I want SA to implement pluggable feature.
I use custom script to list compiled codes in CodeCache.
I guess other troubleshooters also want similar feature (via
jsload) in future if they encounter JVM crash.
Thanks,
Yasumasa
On 2019/12/11 11:52, Chris Plummer wrote:
> Hi,
>
> I like to propose the removal of SA _javascript_ support.
Few people even realize this support exists, and hopefully
even fewer are using it since I'd like to remove it. Since I'm
new to this myself, let me first explain what I know about
it's existence, and then explain why I want to remove it.
>
> If you run "jhsdb clhsdb", there are jsload and jseval
commands. Don't look for them in anything post JDK 8. I'll
explain why later. jsload is used to load a _javascript_ file.
In that file you can register new clhsdb commands that are
written in _javascript_. You can also evaluate _javascript_ using
the jseval command. Some of this is explained in [1], which is
the only place I can find any reference to this support. It
does not appear to be officially supported, nor is there any
oracle provided documentation.
>
> There also appear to be a few clhsdb commands that are
written in _javascript_. Doing a grep for "registerCommand" in
sa.js shows the following:
>
> registerCommand("class", "class name", "jclass");
> registerCommand("classes", "classes", "jclasses");
> registerCommand("dumpclass", "dumpclass { address |
name } [ directory ]", "dclass");
> registerCommand("dumpheap", "dumpheap [ file ]",
"dumpHeap");
> registerCommand("mem", "mem address [ length ]",
"printMem");
> registerCommand("sysprops", "sysprops", "sysProps");
> registerCommand("whatis", "whatis address",
"printWhatis");
>
> Once again, don't go looking for these in anything newer
than JDK8. You won't find them. Again the only documentation I
can fine is [1].
>
> The other use of _javascript_ is the SOQL command (Simple
Object Query Language), a tool used to query the heap, and
also the JSDB command. The only SOQL documentation I could
find is the blog reference [2]. I could not find HSDB
documentation, but I believe is is a _javascript_ support for
looking at hotspot. So once again, neither of these seem to be
officially supported or documented.
>
> The real purpose of the email is to propose removal of
this support. Here are the reasons:
>
> (1) It's broken, and has been since 9. See [3]. This is
why you don't see the _javascript_ related commands in clhsdb.
_javascript_ fails to initialize, so none of the _javascript_
related commands are registered.
> (2) Nashorn is deprecated and will be removed eventually.
> (3) We have very little understanding of the _javascript_
support.
> (4) No resources to work on it (unless there is a
community volunteer).
> (5) Very questionable value (lack of users). The fact
this support has been broken since JDK 9 and no bug was filed
until I did so this week is a good indication of that. Another
is that there are no other SA _javascript_ related bugs filed.
Lastly, the lack of any official documentation and only
minimal mention of it on the web is another good indication of
it's (lack of) value.
>
> Also, regarding the 7 commands listed above that would be
lost (but currently don't work now anyway), if they are really
wanted, they could be implemented in java instead of
_javascript_.
>
> I'd like to remove _javascript_ support in two steps. The
first is simply disable the clhsdb code that tries to
initialize the _javascript_ support. I'd like to do this in 14
(actually as soon as possible). I'd like to actually do this
now even if we decide to keep _javascript_ support and
eventually fix it because it will get rid of the warning you
see whenever you attach from clhsdb:
>
> Warning! JS Engine can't start, some commands will
not be available.
>
> This warning will become more of an issue for the clhsdb
tests after I push [4] because then you will also see the full
stacktrace for the underlying exception that caused the
_javascript_ to fail to start. Besides being unnecessary noise
in passing test cases, it can also be misleading in any test
that fails because the exception will be unrelated to the
failure. This is actually what got me going down this path of
what the _javascript_ support is all about.
>
> The next step would be to strip out all _javascript_
related code, including the SOQL and JSDB tools. This would be
done in 15.
>
> Please let me know what you think.
>
> thanks,
>
> Chris
>
> [1] https://cr.openjdk.java.net/~minqi/6830717/raw_files/new/agent/doc/clhsdb.html
> [2] http://javatroubleshooting.blogspot.com/2015/12/serviceability-agent-part-3.html
> [3] https://bugs.openjdk.java.net/browse/JDK-8235594
> [4] https://bugs.openjdk.java.net/browse/JDK-8234277
>
|
