Hi Sundar,

On 2019/04/15 16:58, Sundararajan Athijegannathan wrote:
Both options are hacks :( Personally I'm not comfortable with either
option.

JSObject wrapper suggested in the bug is not impossible to do.

VM.getVM() would the "initial object" -- a JSObject impl. that walks
through objects is possible. JSObject impls. can cache fields/methods
reflectively and invoke those as needed. If SA class is needed, we can
add JSClassObject impl. (which would a JSObject impl. that'd support
static method/field access).

I guess SA classes will be added / modified due to HotSpot improvement (e.g. 
GC, JIT, etc...)
So I think it is not reasonable to add JSClassObject implementations.

In addition, I guess this restriction is on Nashorn only.
Nashorn might be replaced to Graal.js .

Do we see this issue with other JS Engine?
If not so, I want to use other JS Engine (e,g, Graal).


Thanks,

Yasumasa


-Sundar

On 12/04/19, 7:35 PM, Yasumasa Suenaga wrote:
Hi all,

I saw the message when I attached CLHSDB to target VM as below:

----
javax.script.ScriptException: TypeError: sapkg.runtime.VM.getVM is not
a function in sa.js at line number 54
Warning! JS Engine can't start, some commands will not be available.
----

It has been reported as JDK-8157947.


It is caused that jdk.hotspot.agent module is not exported to
nashorn dynamic module.
The comment in JDK-8157947 says that it will be fixed if we implement
JSObject, but I think it is difficult because we cannot know
what classes in SA are used in user scripts.

So I think two approaches for this issue:


   1. Open all packages in module-info in jdk.hotspot.agent
        I filed suggested fix to JBS, but it is not smart...

   2. Open all packages in JSJavaScriptEngine::<clinit>
        Opens all packages to Module.EVERYONE_MODULE.
        But EVERYONE_MODULE is private field, so we need to access
        from JNI code.
          http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/
        This change has passed serviceability/sa jtreg tests.


Both ideas is hackish, but I prefer to 2. to fix it.
If 2. is accepted I will push it to submit repo and send review request.

What do you think?


Thanks,

Yasumasa

Reply via email to