Removal of SA javascript support

sundararajan.athijegannathan at oracle.com sundararajan.athijegannathan at oracle.com
Wed Dec 11 12:47:15 UTC 2019 

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 
>>>> <suenaga at oss.nttdata.com <mailto: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
>>>>      >
>>>>
>>
>>

More information about the serviceability-dev mailing list