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

[Jaroslav Tulach]

Thanks for your review Mandy.


>> Mandy Chung <mandy.chung at oracle.com>: 25.07.17 @ 11:39 <<
> > On Jul 25, 2017, at 1:33 AM, Doug Simon <doug.simon at oracle.com> wrote:
> >> On 25 Jul 2017, at 01:37, Mandy Chung <mandy.chung at oracle.com> wrote:
> >> 
> >> Vladimir,
> >> 
> >> I believe you don’t want to add the dependency from JVMCI to
> >> java.management.  Otherwise, JVMCI can’t run with only java.base.> 
> > The dependency is unfortunate. Can you suggest how JVMCI platform beans
> > could participate in platform bean registration without the dependency?

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?

> If it exposes a MBean, the dependency would be needed.

Isn't there a way to require an optional dependency? That would be sufficient - 
as the classes in question are only loaded once java.management searches for 
them. E.g. only when java.management is installed.

> One consideration might be to separate the JVMCI MBean provider in its own
> module so that it’s registered only when such module is resolved in the
> module graph.  This way JVMCI can work even if java.management is not
> present.

Yes, I can create something like jdk.internal.vm.ci.management and move the 
JVMCIMXBeans.java (to be renamed to JVMCIMBeans.java per Vladimir's 
suggestion, if I remember correctly) there. This module would have dependency 
on jdk.internal.vm.ci and java.management and bridge them together.

How do I make sure this module is enabled when possible? Or is that automatic?

> >> Is the MBean in jdk.internal.vm.compiler or in Lab’s Graal compiler?
> > 
> > Anything in Lab’s Graal compiler is destined for JDK Graal so the
> > distinction is only temporary at best.
> Good to know.

The bean is in there and implements DynamicMBean interface. E.g. this part of 
Graal compiler module has to have dependency on java.management - that means 
to make that dependency optional or split the module in two, I assume.


> 
> >> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/services/src/jdk/vm/ci/ser
> >> vices/internal/JVMCIMXBeans.java - I suspect this file meant to be in
> >> src/jdk.internal.vm.ci/share/classes/src/jdk.internal.vm.ci/share/classe
> >> s/jdk/vm/ci/services/internal/JVMCIMXBeans.java> 
> > Not sure I follow - there is currently no such directory
> > src/jdk.internal.vm.ci/share/classes/src
> Typo - it’s an existing directory:
> 
> src/jdk.internal.vm.ci/share/classes/jdk.vm.ci.services/src/jdk/vm/ci/servic
> es/internal

The location is probably not correct. I am even surprised the code builds fine. 
Thanks for catching this.

-jt
 
> >>> On Jul 12, 2017, at 2:20 PM, Vladimir Kozlov
> >>> <vladimir.kozlov at oracle.com> wrote:
> >>> 
> >>> https://bugs.openjdk.java.net/browse/JDK-8182701
> >>> webrev:
> >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.jdk/
> >>> http://cr.openjdk.java.net/~kvn/8182701/webrev.hs/
> >>> 
> >>> Contributed by Jaroslav Tulach.
> >>> 
> >>> JDK itself contains quite a lot of platform MBeans which get registered
> >>> "on demand". Graal compiler (jdk.internal.vm.compiler) provides its own
> >>> MBean(s) - however currently there is no way to register it "on
> >>> demand". JDK9 already contains support for collecting platform MBeans
> >>> from various modules. We just need to expose Graal MBean through JVMCI.
> >>> 
> >>> Thanks,
> >>> Vladimir