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

Jaroslav Tulach jaroslav.tulach at oracle.com
Wed Aug 2 14:08:24 UTC 2017

> 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.

This is not possible to do cleanly. When shall Graal register the bean? On 
first compilation? Then it may enable the whole ManagementFactory 
infrastructure too early and influence results of regular Java programs.

We have seen a benchmark failure due to registering the Graal bean too early. 
The bean registration triggered the java.util.logging infrastructure on and as 
a result the benchmarking test failed. 

The test tried to set "java.util.logging.config.file" property and then it 
assumed it will be used on subsequent call to Logger.getLogger(...). But the 
property was ignored as the Logger was already initialized.

I believe that exactly for this reason there is the PlatformManagedObject & 
co. infrastructure. To not trigger the management infrastructure on 
prematurely. All the HotSpot beans are registered "lazily". As part of 
internal JDK infrastructure we believe Graal should have a way to be part of 
such "lazy initialization" too.

I hope the need for the requested functionality is now clearer.

More information about the core-libs-dev mailing list