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
