RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean
mandy.chung at oracle.com
Wed Aug 2 14:37:54 UTC 2017
> On Aug 2, 2017, at 7:08 AM, Jaroslav Tulach <jaroslav.tulach at oracle.com> wrote:
>> 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.
As described in the previous mail, the current way to register a platform
MBean is to have a provider module that provides
sun.management.spi.PlatformMBeanProvider. The provider module will get
resolved during service binding. jdk.management is one example.
More information about the hotspot-compiler-dev