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

[Yasumasa Suenaga]

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