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
