Re: Removal of SA javascript support

[Alan Bateman]

On 20/12/2019 01:08, 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.
JEP 260 describes the rational for the jdk.unsupported module. I don't 
think it is possible to argue that SA is a critical internal API.


You've brought this up a few times and I think the main issue is that SA 
is tightly tied to the HotSpot VM implementation, so SA or anything 
using it directly will need to updated continuously, maybe very build if 
there are data structures changing. I suspect any code using the SA API 
directly really needs to be in the jdk repo, I don't think it would be 
workable to export it unconditionally for tools that are maintained 
outside of the jdk repo.


-Alan

Re: Removal of SA javascript support

[Yasumasa Suenaga]

t 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 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.
 >
 > 

Re: Removal of SA javascript support

[sundararajan . athijegannathan]

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
 >

Re: Removal of SA javascript support

[Yasumasa Suenaga]

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.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 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 appe

Re: Removal of SA javascript support

[Chris Plummer]

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.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 
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");

Re: Removal of SA javascript support

[Yasumasa Suenaga]

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.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 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", "w

Re: Removal of SA javascript support

[Yasumasa Suenaga]

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 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

Re: Removal of SA javascript support

[Ioi Lam]

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.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
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 

Re: Removal of SA javascript support

[Dmitry Samersoff]

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.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
>>>>> 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 

Re: Removal of SA javascript support

[sundararajan . athijegannathan]

Replacing one scripting language with another (jython) does not solve 
anything. You'd still face the same issues - accessing module private 
stuff from SA module from scripts. Besides you'll have a new problem in 
addition. How to bundle jython? We've been using bundled scripting 
engine (nashorn) so far.


-Sundar

On 11/12/19 1:14 pm, Dmitry Samersoff wrote:

Hello Chris,

I'm supporting you with this decision.

PS: For people who want SA scripting -

One thing I experimented with a long time ago -
has been exporting of some SA capabilities to jython.
This might be the way to go.

-Dmitry



On 11.12.19 05: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/~minq

Re: Removal of SA javascript support

[sundararajan . athijegannathan]

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 
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 i

Re: Removal of SA javascript support

[Dmitry Samersoff]

Hello Chris,

I'm supporting you with this decision.

PS: For people who want SA scripting -

One thing I experimented with a long time ago -
has been exporting of some SA capabilities to jython.
This might be the way to go.

-Dmitry



On 11.12.19 05: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
> 

Re: Removal of SA javascript support

[Yasumasa Suenaga]

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 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 si

Re: Removal of SA javascript support

[Chris Plummer]

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 
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 dec

Re: Removal of SA javascript support

[Chris Plummer]

  
  
It probably would not be that hard to
  get SA to load a .class file and call some init function in it,
  which in turn could register commands. There is already a
  CommandProcessor.registerCommand() for adding _javascript_ commands.
  It can easily be overloaded to add a version for registering
  commands implemented in java. One thing I'm a bit unclear on is
  how modules would play a role in this, and the ability for the
  commands to access all the internal SA APIs, which I think they
  would likely need.
  
  Chris
  
  On 12/10/19 9:39 PM, 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?


[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 
  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 

Re: Removal of SA javascript support

[Yasumasa Suenaga]

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...


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 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:
 >
 >   Warn

Re: Removal of SA javascript support

[Krystal Mok]

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?

[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 
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, so

Re: Removal of SA javascript support

[Yasumasa Suenaga]

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

Re: Removal of SA javascript support

[Krystal Mok]

Thank you very much for the work on the JS support in SA, Sundar! I really
loved it and depended on it. That's why back in the day when the JS support
was broken from time to time I'd get affected and annoyed and send fixes
for them...

A bit of suggestion: I still see a lot of value for having a proper REPL
beyond CLHSDB for the same purposes as the JS support. Would it be possible
for the serviceability team or someone from the community to invest in
integrating JShell into the SA world?

Thanks,
Kris

On Tue, Dec 10, 2019 at 7:38 PM 
wrote:

> Hi Kris,
>
> Glad to hear that someone used JS interface of SA :) Quick prototyping +
> debugger interactive scripting were the goals of JS interface! As you
> mentioned, given the current state of SA JS interface, it has to be removed
> :(
>
> Thanks
>
> -Sundar
> On 11/12/19 8:56 am, Krystal Mok wrote:
>
> Hi Chris,
>
> Thanks for the proposal. I used to be one of the few heavy users of jsload
> / jseval in CLHSDB back in the JDK6 to JDK8 era. The way I used to use it
> is to quickly prototype new functionality in JS and later bake it into Java
> code, and also for exploring heap dumps beneath the existing commands
> available in CLHSDB (i.e. the underlying SA API is far more powerful than
> the set of commands exposed in HSDB).
>
> I even collected my own library of SA-based JS functions for easy
> navigation of Java heap dumps. e.g. this objtree command:
> https://gist.github.com/rednaxelafx/1393698#file-objtree-js
>
> I'm sad to see it go but given its current state I'd +1 on the proposal to
> remove it now.
>
> Best regards,
> Kris
>
> On Tue, Dec 10, 2019 at 6:52 PM 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 

Re: Removal of SA javascript support

[sundararajan . athijegannathan]

Hi Kris,

Glad to hear that someone used JS interface of SA :) Quick prototyping + 
debugger interactive scripting were the goals of JS interface! As you 
mentioned, given the current state of SA JS interface, it has to be 
removed :(


Thanks

-Sundar

On 11/12/19 8:56 am, Krystal Mok wrote:

Hi Chris,

Thanks for the proposal. I used to be one of the few heavy users of 
jsload / jseval in CLHSDB back in the JDK6 to JDK8 era. The way I used 
to use it is to quickly prototype new functionality in JS and later 
bake it into Java code, and also for exploring heap dumps beneath the 
existing commands available in CLHSDB (i.e. the underlying SA API is 
far more powerful than the set of commands exposed in HSDB).


I even collected my own library of SA-based JS functions for easy 
navigation of Java heap dumps. e.g. this objtree command: 
https://gist.github.com/rednaxelafx/1393698#file-objtree-js


I'm sad to see it go but given its current state I'd +1 on the 
proposal to remove it now.


Best regards,
Kris

On Tue, Dec 10, 2019 at 6:52 PM Chris Plummer 
mailto:chris.plum...@oracle.com>> 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 

Re: Removal of SA javascript support

[Krystal Mok]

Hi Chris,

Thanks for the proposal. I used to be one of the few heavy users of jsload
/ jseval in CLHSDB back in the JDK6 to JDK8 era. The way I used to use it
is to quickly prototype new functionality in JS and later bake it into Java
code, and also for exploring heap dumps beneath the existing commands
available in CLHSDB (i.e. the underlying SA API is far more powerful than
the set of commands exposed in HSDB).

I even collected my own library of SA-based JS functions for easy
navigation of Java heap dumps. e.g. this objtree command:
https://gist.github.com/rednaxelafx/1393698#file-objtree-js

I'm sad to see it go but given its current state I'd +1 on the proposal to
remove it now.

Best regards,
Kris

On Tue, Dec 10, 2019 at 6:52 PM 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