8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent

[Sundararajan Athijegannathan]

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

-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