Removal of SA javascript support
sundararajan.athijegannathan at oracle.com
sundararajan.athijegannathan at oracle.com
Wed Dec 11 03:38:16 UTC 2019
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.plummer at oracle.com <mailto:chris.plummer at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20191211/2d055600/attachment.htm>
More information about the serviceability-dev
mailing list