Thanks for your review Mandy.
>> Mandy Chung <mandy.ch...@oracle.com>: 25.07.17 @ 11:39 << > > On Jul 25, 2017, at 1:33 AM, Doug Simon <doug.si...@oracle.com> wrote: > >> On 25 Jul 2017, at 01:37, Mandy Chung <mandy.ch...@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.koz...@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
