Removal of SA javascript support

Wed Dec 11 05:39:27 UTC 2019

Hi Yasumasa,

That's a very nice idea. Basically what you're asking for is exposing the
Command interface [1] so that plugins can implement it and get dynamically
loaded / registered into CLHSDB / HSDB, right?

[1]:
http://hg.openjdk.java.net/jdk/jdk/file/c71ec1f09f21/src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/CommandProcessor.java#l246

- Kris

On Tue, Dec 10, 2019 at 9:33 PM Yasumasa Suenaga <suenaga at oss.nttdata.com>
wrote:

> Hi Chris,
>
> It's a sad proposal, but I agree with you. To maintain SA in JS is
> difficult since Jigsaw.
> However I want SA to implement pluggable feature.
> I use custom script to list compiled codes in CodeCache.
>
> I guess other troubleshooters also want similar feature (via jsload) in
> future if they encounter JVM crash.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2019/12/11 11: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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20191210/be78609a/attachment.htm>