Removal of SA javascript support
Chris Plummer
chris.plummer at oracle.com
Wed Dec 11 06:00:54 UTC 2019
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