Sundar, Supporting hotspot data structure in SA is already a maintenance nightmare ;)
So we can consider to provide high level API, like find_class_by_name to script writer. It allows anybody who are interesting with quick prototyping write his own program on top of SA with any language they want. -Dmitry On 11.12.19 15:47, sundararajan.athijegannat...@oracle.com wrote: > Effectively you're asking for SA as API. I don't think that is a good > idea. That implies supporting hotspot data structures as Java *API*. > That will be maintainability nightmare - we've to keep tracking hotspot > data structures in SA code. That itself is problematic. API would be > next level nightmare. > > -Sundar > > On 11/12/19 11:57 am, Yasumasa Suenaga wrote: >> Hi, >> >> IMHO we need to export all packages in SA if we do not provide new API >> for SA. >> sa.js in jdk.hotspot.agent could access all SA classes until JDK 8 >> (before Jigsaw), so we could make various functions if we need. >> >> OTOH we cannot know what classes are needed by the SA users. All >> packages in jdk.hotspot.agent module provides features, and they >> require other packages. For example, sun.jvm.hotspot.oops.Oop requires >> sun.jvm.hotspot.types, and it requires sun.jvm.hotspot.debugger . >> It is difficult to track and to export minimally. >> (I worked for it in JDK-8157947, but I gave up...) >> >> Thus I guess it is a big challenge to export SA classes without >> refactoring. >> If we provide new API for SA plugin, I guess we need to work some >> refactoring. >> >> >> Yasumasa >> >> >> On 2019/12/11 15:00, Chris Plummer wrote: >>> On 12/10/19 9:56 PM, Yasumasa Suenaga wrote: >>>> On 2019/12/11 14:39, Krystal Mok wrote: >>>>> 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? >>>> >>>> Yes, but we also need proxy API to access internal SA objects e.g. >>>> CodeCache, JavaThread, TypeDataBase, etc... >>>> >>> Yes, or export them. I should have read this email before posting my >>> previous one. >>> >>> Chris >>>> >>>> Yasumasa >>>> >>>> >>>>> [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 <mailto: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 >>>>> > >>>>> >>> >>>
