[1]:
http://hg.openjdk.java.net/jdk/jdk/file/c71ec1f09f21/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java#l246
- Kris
On Tue, Dec 10, 2019 at 9:33 PM Yasumasa Suenaga
<suen...@oss.nttdata.com <mailto:suen...@oss.nttdata.com>> wrote:
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
>
