Hi Kris,
Glad to hear that someone used JS interface of SA :) Quick prototyping +
debugger interactive scripting were the goals of JS interface! As you
mentioned, given the current state of SA JS interface, it has to be
removed :(
Thanks
-Sundar
On 11/12/19 8:56 am, Krystal Mok wrote:
Hi Chris,
Thanks for the proposal. I used to be one of the few heavy users of
jsload / jseval in CLHSDB back in the JDK6 to JDK8 era. The way I used
to use it is to quickly prototype new functionality in JS and later
bake it into Java code, and also for exploring heap dumps beneath the
existing commands available in CLHSDB (i.e. the underlying SA API is
far more powerful than the set of commands exposed in HSDB).
I even collected my own library of SA-based JS functions for easy
navigation of Java heap dumps. e.g. this objtree command:
https://gist.github.com/rednaxelafx/1393698#file-objtree-js
I'm sad to see it go but given its current state I'd +1 on the
proposal to remove it now.
Best regards,
Kris
On Tue, Dec 10, 2019 at 6:52 PM Chris Plummer
<chris.plum...@oracle.com <mailto:chris.plum...@oracle.com>> 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
