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

[Doug Simon]

Hi Jaroslav,

In general, thanks for pushing through with this change.

I don't think JVMCIMXBeans should be in the hotspot-agnostic jdk.vm.ci.services.internal package since it has a direct reference to HotSpotJVMCIRuntime. I would suggest moving it to jdk.vm.ci.hotspot.

In HotSpotJVMCRuntime.java:

 558     public String mbeanName() {
 568     public Object mbean() {

Any reason these methods don't follow the conventions of other getter methods in this class (i.e. getMBeanName() and getMBean())?

  95     /** Name of the {@link MBeanInfo MBean} representing the internals

This should be:

/**
 * Gets the name of the ...

Same comment for mbean() method. Also {@code null} is used in JVMCI instead of <code>null</code>.

-Doug

> On 18 Aug 2017, at 20:49, Vladimir Kozlov <vladimir.kozlov at oracle.com> 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
>>> 
>>>