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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jaroslav Tulach-4
Thanks for your review Mandy.


>> Mandy Chung <[hidden email]>: 25.07.17 @ 11:39 <<
> > On Jul 25, 2017, at 1:33 AM, Doug Simon <[hidden email]> wrote:
> >> On 25 Jul 2017, at 01:37, Mandy Chung <[hidden email]> 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
> >>> <[hidden email]> 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


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jaroslav Tulach-4
> This is Graal-specific MBean.  It doesn’t seem that it must be registered as
> “platform mbean” which has to implement PlatformManagedObject.
>
> Graal can register the MBean at runtime when java.management is present by
> calling ManagementFactory.getPlatformMBeanServer().registerMBean method.
> That seems to be a better alternative.  Separating the MBean in a different
> module would still be applicable.

This is not possible to do cleanly. When shall Graal register the bean? On
first compilation? Then it may enable the whole ManagementFactory
infrastructure too early and influence results of regular Java programs.

We have seen a benchmark failure due to registering the Graal bean too early.
The bean registration triggered the java.util.logging infrastructure on and as
a result the benchmarking test failed.

The test tried to set "java.util.logging.config.file" property and then it
assumed it will be used on subsequent call to Logger.getLogger(...). But the
property was ignored as the Logger was already initialized.

I believe that exactly for this reason there is the PlatformManagedObject &
co. infrastructure. To not trigger the management infrastructure on
prematurely. All the HotSpot beans are registered "lazily". As part of
internal JDK infrastructure we believe Graal should have a way to be part of
such "lazy initialization" too.

I hope the need for the requested functionality is now clearer.
-jt



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jaroslav Tulach-4
In reply to this post by Jaroslav Tulach-4
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.

Thanks for your support so far.
-jt
 

> >> 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.
>
> There is `requires static` but it would be a lot cleaner if the
> management support could be refactored into its own service provider
> module, meaning JVMCIMXBeans would be in its own module.
>
> -Alan


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jaroslav Tulach-4
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


Loading...