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
