Removal of SA javascript support

sundararajan.athijegannathan at oracle.com sundararajan.athijegannathan at oracle.com
Fri Dec 20 03:25:44 UTC 2019 

Hi,

I am going to reiterate. This will lead to maintenance nightmare! Any 
"Unsupported Java API" is still an API! Remember Unsafe? Once blessed in 
any form, it is very difficult to remove. Exposing hotspot VM internals 
as a Java API is very bad idea. No, not even as "unsupported API".

Exposing SA to scripts was a different beast. Scripting languages are 
dynamically typed. It is quite common in scripting world to check the 
existence of an attribute & then use it (if (!obj["foo"]) / if (typeof 
obj["foo"] == 'function') kind of code).  That'd be extremely painful in 
a statically typed language like Java (reflection or method/var 
handles?).  Platform debuggers like dbx support a scripting language 
along with access to the data structures from the target process. SA 
scripting was inspired from that model. Also scripts were never meant to 
be written & maintained for long time! Most scripts were expected to be 
written for a specific debugging exercise/session (thrown away).

-Sundar

On 20/12/19 6:38 am, Yasumasa Suenaga wrote:
> Hi Chris,
>
> Can we treat (part of) jdk.hotspot.agent like jdk.unsupported module?
> jdk.unsupported exports unspec'd API like Unsafe.
>
> If we do so, we might need to separate SA API into exported class and 
> internal class.
>
> I've proposed to export all SA packages in JDK-8157947, but it was 
> rejected.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2019/12/20 1:28, Chris Plummer wrote:
>> Hi Yasumasa,
>>
>> I've had similar thoughts about how to extend clhsdb. Why not export 
>> everything since what we would export is not part of a spec, and the 
>> javascript support had the same issue of potentially breaking when 
>> the SA API changed. But maybe this type of unspec'd API exporting is 
>> considered bad policy. I'm not sure. I'll let the API spec guru's 
>> comment on that aspect of it.
>>
>> thanks,
>>
>> Chris
>>
>> On 12/19/19 12:17 AM, Yasumasa Suenaga wrote:
>>> Hi,
>>>
>>> I think we can provide API for SA as following:
>>>
>>>   Patch: http://cr.openjdk.java.net/~ysuenaga/sa-api/webrev/
>>>   Plugin examples:
>>>     browse: 
>>> http://cr.openjdk.java.net/~ysuenaga/sa-api/plugin-examples/
>>>     download: 
>>> http://cr.openjdk.java.net/~ysuenaga/sa-api/plugin-examples.tar.gz
>>>
>>> I think JS plugin (loading via `jsload` CLHSDB command) was 
>>> supported "AS IS".
>>> If HotSpot and/or SA code is changed, the user should follow it if 
>>> need.
>>> SA is not part of Java SE. We need not to maintain SA API when it 
>>> happen IMHO.
>>>
>>> The user who want to expand SA features (includes me!) should have 
>>> responsible for it.
>>> So I did not expose jdk.hotspot.agent module - the user need to 
>>> build with --add-exports.
>>>
>>> My proposal can write SA plugins with pure Java. So we don't need to 
>>> depend on script engine.
>>>
>>>
>>> Comments are welcome.
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2019/12/11 21:47, sundararajan.athijegannathan at 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 
>>>>>>>> <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