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

Yasumasa Suenaga yasuenag at gmail.com
Thu May 2 08:35:46 UTC 2019


 > Would it be possible re-outline the problem and/or include the 
exception that is being observed?

We can see TypeError thrown by Nashorn when we attach CLHSDB.
It means JS in jdk.hotspot.agent (sa.js) could not call 
sun.jvm.hotspot.runtime.VM::getVM .

It is caused that jdk.hotspot.agent does not export to 
jdk.scripting.nashorn.scripts module.
I tried to open all SA packages to everyone, it works fine [1].

IMHO it would be convenience that module API provides method(s) to open 
to everyone, or --add-opens option can open modules to everyone.

Anyway, I think this issue may occur any applications that JS calls Java 
world. Thus I hope this issue would be resolved in scripting API or 
module system.
If so, SA should use it :-)


Thanks,

Yasumasa



[1] http://cr.openjdk.java.net/~ysuenaga/JDK-8157947/proposal/



On 2019/05/02 15:30, Alan Bateman wrote:
> On 02/05/2019 06:47, Sundararajan Athijegannathan wrote:
>> 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.
> This exports sun.jvm.hotspot.utilities.soql.wrapper unconditionally so 
> it's adding a JDK-specific API. Would it be possible re-outline the 
> problem and/or include the exception that is being observed? If 
> jdk.hotspot.agent is going to export an API then it will need a lot of 
> javadoc work and of course a CSR (and no guarantee that the CSR would be 
> approved because we agreed in JDK 9 that jdk.hotspot.agent would be a 
> supported interface).
> 
> -Alan


More information about the serviceability-dev mailing list