[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: 8157947: SA: Javascript engine can't access internal packages of jdk.hotspot.agent
From:       Yasumasa Suenaga <yasuenag () gmail ! com>
Date:       2019-04-19 13:07:52
Message-ID: b4ecec1e-33f5-3366-234b-efeaea90829e () gmail ! com
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]