[10] RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean

[Mandy Chung]

> On Jul 27, 2017, at 2:07 AM, Jaroslav Tulach <jaroslav.tulach at oracle.com> wrote:
> 
>> One consideration might be to separate the JVMCI MBean provider in its own
>> module so that it’s registered only when such module is resolved in the
>> module graph.  This way JVMCI can work even if java.management is not
>> present.
> 
> Yes, I can create something like jdk.internal.vm.ci.management and move the 
> JVMCIMXBeans.java (to be renamed to JVMCIMBeans.java per Vladimir's 
> suggestion, if I remember correctly) there. This module would have dependency 
> on jdk.internal.vm.ci and java.management and bridge them together.
> 
> How do I make sure this module is enabled when possible? Or is that automatic?
> 

Service binding will resolve a service provider module during resolution.  In other words, if java.management is in the resolved graph, any modules providing the services it uses will be added to the graph.

>>>> Is the MBean in jdk.internal.vm.compiler or in Lab’s Graal compiler?
>>> 
>>> Anything in Lab’s Graal compiler is destined for JDK Graal so the
>>> distinction is only temporary at best.
>> Good to know.
> 
> The bean is in there and implements DynamicMBean interface. E.g. this part of 
> Graal compiler module has to have dependency on java.management - that means 
> to make that dependency optional or split the module in two, I assume.

This is Graal-specific MBean.  It doesn’t seem that it must be registered as “platform mbean” which has to implement PlatformManagedObject.

Graal can register the MBean at runtime when java.management is present by calling ManagementFactory.getPlatformMBeanServer().registerMBean method.  That seems to be a better alternative.  Separating the MBean in a different module would still be applicable.

Mandy