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

[Yasumasa Suenaga]

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