Removal of SA javascript support

[sundararajan.athijegannathan at oracle.com]

Replacing one scripting language with another (jython) does not solve 
anything. You'd still face the same issues - accessing module private 
stuff from SA module from scripts. Besides you'll have a new problem in 
addition. How to bundle jython? We've been using bundled scripting 
engine (nashorn) so far.

-Sundar

On 11/12/19 1:14 pm, Dmitry Samersoff wrote:
> 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
>>