Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

[David Holmes]

Hi Doug,

Not a review. :) Just wondering what HotSpotRuntimeMBean has to do with 
this ???


Thanks,
David

On 13/04/2018 4:24 AM, Doug Simon wrote:

Please review this change that removes the existing Graal service provider for 
hooking into the Platform MBean Server and makes 
jdk.internal.vm.compiler.management an upgradeable module.

Please refer to 
https://bugs.openjdk.java.net/browse/JDK-8187490?focusedCommentId=14170942=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14170942
 for discussion on the latter point.

The Graal changes that dynamically register an MBean for accessing Graal will 
be part of a subsequent Graal update.

http://cr.openjdk.java.net/~dnsimon/8187490/

-Doug

Re: RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

[mandy chung]

On 4/13/18 2:24 AM, Doug Simon wrote:

Please review this change that removes the existing Graal service provider for 
hooking into the Platform MBean Server and makes 
jdk.internal.vm.compiler.management an upgradeable module.

Please refer to 
https://bugs.openjdk.java.net/browse/JDK-8187490?focusedCommentId=14170942=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14170942
 for discussion on the latter point.

The Graal changes that dynamically register an MBean for accessing Graal will 
be part of a subsequent Graal update.

http://cr.openjdk.java.net/~dnsimon/8187490/




This looks okay.   jdk.internal.vm.compiler.management will become empty 
until the next Graal update and I guess this makes it easier to make 
Graal change in the upstream project.   This is fine with me.


Mandy

RFR: 8187490: HotSpotRuntimeMBean should be moved to Graal management module

[Doug Simon]

Please review this change that removes the existing Graal service provider for 
hooking into the Platform MBean Server and makes 
jdk.internal.vm.compiler.management an upgradeable module.

Please refer to 
https://bugs.openjdk.java.net/browse/JDK-8187490?focusedCommentId=14170942=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14170942
 for discussion on the latter point.

The Graal changes that dynamically register an MBean for accessing Graal will 
be part of a subsequent Graal update.

http://cr.openjdk.java.net/~dnsimon/8187490/

-Doug

Re: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

[Rafael Winterhalter]

I have not thought of that but you are of course right, that works. The
solution is however far from pretty as it needs a case basis since the
resolution of the proxy class is only possible if the proxy is in fact
loaded into an unnamed module what is not always the case. This does
however cover all cases for Java 9 and Java 10 proxies. I do however hope
Java 11 can ship with something more convenient then this:
https://gist.github.com/raphw/c1faf2f40e80afce6f13511098cfb90f

Thanks for guiding me through that!
Best regards, Rafael

2018-04-12 10:40 GMT+02:00 Alan Bateman :

> On 11/04/2018 21:07, Rafael Winterhalter wrote:
>
>> I do not think that this is possible. If the module containing the
>> interface does not open a package, I cannot change the privileges of the
>> main module such that I can resolve a method handle for invoking the
>> special invocation.
>>
>> I just tried this out too and I did not find a way, could you suggest how
>> to change my code for being able to do so?
>>
> If the interface is public in an exported package (no need for the package
> to be open) then the proxy will be generated into the unnamed module. So
> easy to get a Lookup to the proxy class and you can use this as the special
> caller. Can you change your invocation handler to the following and try it:
>
> Class proxyClass = proxy.getClass();
> Main.class.getModule().addReads(proxyClass.getModule());
> Lookup lookup = MethodHandles.privateLookupIn(proxyClass,
> MethodHandles.lookup());
> MethodType mt = MethodType.methodType(String.class);
> return lookup.findSpecial(iface, "foo", mt, proxyClass).bindTo(proxy).invo
> keWithArguments();
>
> -Alan
>

Re: Avoiding sun.misc.Unsafe and embracing modules in Java libraries: missing links

[Alan Bateman]

On 11/04/2018 21:07, Rafael Winterhalter wrote:
I do not think that this is possible. If the module containing the 
interface does not open a package, I cannot change the privileges of 
the main module such that I can resolve a method handle for invoking 
the special invocation.


I just tried this out too and I did not find a way, could you suggest 
how to change my code for being able to do so?
If the interface is public in an exported package (no need for the 
package to be open) then the proxy will be generated into the unnamed 
module. So easy to get a Lookup to the proxy class and you can use this 
as the special caller. Can you change your invocation handler to the 
following and try it:


Class proxyClass = proxy.getClass();
Main.class.getModule().addReads(proxyClass.getModule());
Lookup lookup = MethodHandles.privateLookupIn(proxyClass, 
MethodHandles.lookup());

MethodType mt = MethodType.methodType(String.class);
return lookup.findSpecial(iface, "foo", mt, 
proxyClass).bindTo(proxy).invokeWithArguments();


-Alan