Removal of SA javascript support
Ioi Lam
ioi.lam at oracle.com
Wed Dec 11 22:24:02 UTC 2019
Regarding maintaining hotspot data structures in SA, I think we often
break it without knowing, especially when we are adding data structures
that are not currently exposed by SA.
Does anyone have a sense of the state of SA in newer versions of the
JDK. Is SA still doing what you expect, or do you see a declining level
of usefulness because SA is getting more out-of-sync?
Thanks
On 12/11/19 7:03 AM, Dmitry Samersoff wrote:
> 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.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