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
>
