> On Aug 2, 2017, at 7:08 AM, Jaroslav Tulach <jaroslav.tul...@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. Mandy
