RFR(M) 8182701: Modify JVMCI to allow Graal Compiler to expose platform MBean
jaroslav.tulach at oracle.com
Thu Jul 27 09:09:37 UTC 2017
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
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:
The location is probably not correct. I am even surprised the code builds fine.
Thanks for catching this.
> >>> 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
More information about the hotspot-compiler-dev