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

mandy chung mandy.chung at oracle.com
Mon Aug 21 19:42:09 UTC 2017


cc'ing serviceability-dev which is the right mailing list for platform 
management discussion.

JVMCI is currently named as `jdk.internal.vm.ci` (a JDK internal 
module).   I suppose this new module is intended to be kept as an 
internal module?

   30  * @since 9

should be @since 10.

JVMCIMBeans.java

   55         @Override
   56         public Set<Class<?>> mbeanInterfaces() {
   57             return Collections.singleton(mbean.getClass());
   58         }

This mbeanInterfaces method should return the MBean interface class but 
not the class of the mbean implementation.  This allows the platform 
mbean to be looked up from ManagementFactory.getPlatformMXBean.  If this 
is a dynamic mbean, then this method simply returns an empty list (see 
DiagnosticCommandMBean).    To support standard mbean, 
HotSpotJVMCICompilerFactory::mbeans method would need to include the 
mbean interface type in addition to the name and the mbean 
implementation object, i.e. may need to define a specific type for it.

Mandy


On 8/18/17 11:49 AM, Vladimir Kozlov wrote:
> Updated changes in all repos: 
> http://cr.openjdk.java.net/~kvn/8182701/webrev.01/
>
> On 8/18/17 7:12 AM, Jaroslav Tulach wrote:
>
> Thanks for pushing me forward, Vladimir. Yes, the changes are still 
> needed if
> we want the Graal compiler to expose its MBean in a lazy way. I am 
> offering
> new webrev for review. It contains following changes:
>
> Per Mandy's suggestion I created new module jdk.vm.ci.management to 
> bridge between
> JVMCI and jdk.management. Adding new module was a bit tricky, but with 
> great help of Jan
> Lahoda I even managed to register it as a boot module.
>
> I renamed the JVMCIMXBean class and dropped X per Vladimir's advice. I 
> fixed
> the non-standard location of JVMCIMXBean class.
>
> I changed the interface to use Map, so the compiler is able to expose 
> more
> than a single bean.
>
> That's it. I am looking forward to your review comments.
> -jt
>
> Here are original changes for reference:
>
> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/
> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/
>
> On 8/17/17 11:54 AM, Vladimir Kozlov wrote:
>> Hi Jaroslav,
>>
>> What we should do with 8182701? Do you still need JVMCI changes?
>>
>> Note, your changes to Graal [GR-5435] were integrated recently into 
>> JDK (jdk10/hs):
>> https://bugs.openjdk.java.net/browse/JDK-8186158
>>
>> Thanks,
>> Vladimir
>>
>> On 8/14/17 10:06 AM, Jaroslav Tulach wrote:
>>> On čtvrtek 3. srpna 2017 17:03:39 CEST Jaroslav Tulach wrote:
>>>> On čtvrtek 27. července 2017 15:01:17 CEST Alan Bateman wrote:
>>>>> On 27/07/2017 10:07, Jaroslav Tulach wrote:
>>>>>> Yes, it seems like a desirable goal to let Graal compiler work 
>>>>>> with just
>>>>>> java.base. Is there a description how to build JDK9/10 with just
>>>>>> java.base
>>>>>> that I could follow and test against?
>>>>>
>>>>> You can use jlink to create a run-time image that only contains
>>>>> java.base (jlink --module-path $JAVA_HOME/jmods --add-modules 
>>>>> java.base
>>>>> --output smalljre).
>>>>
>>>> Status update: I've just tried to run Graal compiler against JDK9 
>>>> with only
>>>> java.base and jdk.internal.vm.ci modules, and there are some 
>>>> problems. I
>>>> need to resolve them first before I provide updated version of my 
>>>> patch.
>>>
>>> FYI: As of
>>> https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0 
>>>
>>> the Graal compiler can run with java.base, jdk.unsupported and 
>>> jdk.vm.ci only
>>> modules. But it wasn't easy, especially the 
>>> http://wiki.apidesign.org/wiki/PropertyChangeListener required a bit 
>>> of work.
>>>
>>> -jt
>>>
>>>



More information about the serviceability-dev mailing list