I discussed with Kris about this in OpenJDK Committers' Workshop last year.
In case of .NET Core, SOS is provided to integrate runtime debugging feature to 
native debugger.
If same feature will be provided, I'm very happy!

For example, GDB and WinDbg provides remote debug server.
If (CL)HSDB can connect to native debugger, we can gather data in Java layer 
via them.
I think we can delegate most of memory access to native debugger.
Also we can run custom scripts on GDB. Then I think we need minimum support for 
Java call frames, OOP, and SymbolTable.


Yasumasa


On 2019/12/11 21: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
     >



Reply via email to