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

[Sundararajan Athijegannathan]

Hi Yasumasa,

Response comments inlined below..


On 16/04/19, 5:21 AM, Yasumasa Suenaga wrote:
> 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.

We need to add only *one* JSClassObject class (which can expose static 
fields/methods of a given java.lang.Class which is maintained as an 
instance field).

Also, we may need to add a hook for looking for a class (like Java.type 
- but constructs JSClassObject instance instead).
>
> In addition, I guess this restriction is on Nashorn only.
> Nashorn might be replaced to Graal.js .

I'm not sure. If a JS implementation is module aware, it'll have the 
same issue. The core issue issue here we don't want public/exposed API 
from hotspot module. But we want to allow access to hotspot types, 
methods *only* from scripts => we need some sort of backdoor. I'd like 
JS reflection (JSObject) based backdoors rather than breaking module 
boundary using JNI code.

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

Yes, definitely no harm trying to see if other impls. have the same 
issue or not.

Thanks,
-Sundar
>
>
> 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