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

[Sundararajan Athijegannathan]

Hi Yasumasa

Thanks for confirming that we've the same issue with Graal.js as well. I 
think JSObject impl. idea should be investigated. I think there is 
similar (script) reflective API in Graal.js as well.

Thanks
-Sundar

On 17/04/19, 7:37 PM, Yasumasa Suenaga wrote:
> Hi Sundar,
>
> On 2019/04/16 13:32, Sundararajan Athijegannathan wrote:
>> 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.
>
> I tried to use Graal in CLHSDB, but it did not work well.
> Graal.js uses j.l.r.Proxy which is defined by dynamic module.
> So I saw IllegalAccessError when CLHSDB attempt to call VM.getVM().
>
>
> Thanks,
>
> Yasumasa
>
>
>> 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