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

[Sundararajan Athijegannathan]

Hi Yasumasa,

Sorry for delayed response. Your webrev looks like a good start! 
Unfortunately, dependency on nashorn is inevitable. But there is a 
similar (but different) object API for Graal.js. In future, someone may 
have to do some porting work.

Thanks,
-Sundar

On 19/04/19, 6:37 PM, Yasumasa Suenaga wrote:
> Hi Sundar,
>
> I tried to implement JSObject for SA.
> Following webrev is not completed, but it can get VM object
> and Debugger in it from sa.js:
>
>   http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/jsobject.work/
>
> It is not completed (error will occur when CLSDB is attached.)
> but I want to hear your opinion. So I share it.
>
> AFAIK JSObject impl. idea needs to use AbstractJSObject, but it is
> provided by jdk.scripting.nashorn module.
> However Nashorn has been deprecated by JEP 335 and it might be removed.
>
> Can we fix this issue not to depend on jdk.scripting.nashorn module?
> If it can't, is it allowed to use deprecated module?
>
> I guess Nashorn might be replaced to Graal.js in the future.
> So I concern it is not better to depend on Nashorn.
>
>
> Thanks,
>
> Yasumasa
>
>
> On 2019/04/19 11:36, Sundararajan Athijegannathan wrote:
>> 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