Removal of SA javascript support

[Dmitry Samersoff]

Hello Chris,

I'm supporting you with this decision.

PS: For people who want SA scripting -

One thing I experimented with a long time ago -
has been exporting of some SA capabilities to jython.
This might be the way to go.

-Dmitry



On 11.12.19 05: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
>