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 <suen...@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 > > >
