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
