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

[Mandy Chung]

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

Mandy