JDK-8182701 : Modify JVMCI to allow Graal Compiler to expose platform MBean
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 9,10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-06-22
  • Updated: 2017-11-10
  • Resolved: 2017-09-29
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b31Fixed
Related Reports
Relates :  
JDK-8187490 - HotSpotGraalMBean should be moved to Graal management module
Relates :  
JDK-8187114 - Replace Graal's use of the management API
Description
JDK itself contains quite a lot of platform MBean which get registered "on demand". Graal compiler (just like classical ones) provides its own MBean(s) - however there is no way to register it "on demand".

The current solution is using a reflection check to find out if the MX bean subsystem is initialized and if so, register programmatically.  See:
https://github.com/graalvm/graal/blob/f464ee3b105470b13050e080c9f119bd5f524f9c/compiler/src/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/HotSpotGraalMBean.java#L88
This has two drawbacks: the Graal MBean is registered with a delay and the approach doesn't really work on JDK9.

JDK9 already contains support for collecting platform MBeans from various modules. We just need to expose it to JVMCI compiler.
Comments
The webrev #5 seems to be acceptable. Vladimir, can you please integrate my changes into JDK10 repository once it is open for integrations? Thanks.
20-09-2017
webrev #5: http://cr.openjdk.java.net/~jtulach/8182701/webrev.05/ adjusted to consolidated structure of JDK10 and comments by Mandy and Daniel.
15-09-2017
Alternative proposal is available at **outdated** http://cr.openjdk.java.net/~jtulach/8182701/webrev.03/ **outdated** http://cr.openjdk.java.net/~jtulach/8182701/webrev.04 - the proposal #3 had a bunch of problems especially need to use reflection at line 54 of http://cr.openjdk.java.net/~jtulach/8182701/webrev.03/hotspot/src/jdk.internal.vm.compiler.management/share/classes/org/graalvm/compiler/hotspot/jmx/GraalMBeans.java.html the updated proposal #4 fixes that by moving the jdk.internal.compiler.management module to list of PLATFORM_MODULES as suggested by Mandy.
04-09-2017
JDK-8187114 suggests the replacement of the management API that Graal uses which is orthogonal to JDK-8182701 that exposes a platform MBean for Graal.
01-09-2017
Introducing a Graal management module to provider sun.management.spi.PlatformMBeanProvider is the right solution. In that case, jdk.internal.vm.compiler should eliminate its dependency to java.management and jdk.management [1]. It's fine with me if you want to file a separate issue to eliminate such dependences. [1] https://github.com/graalvm/graal/commit/ca9071941a1be7f1a3725529ecc231ff621d5ed0
01-09-2017
The Graal Compiler side of the change is here https://github.com/JaroslavTulach/graal/commit/20ce1be82112e2d66cbadc45ff380d4b6ec53914
24-08-2017
Implementation of this issue is currently under review as http://cr.openjdk.java.net/~kvn/8182701/webrev.01/
21-08-2017
ILW = no way to register Graal MBeans on demand; experimental feature; using reflection check, register programmatically = HLM = P3
12-07-2017
Guys, do you need help with reviews and push into JDK 10?
30-06-2017
I lowed priority to remove it from JDK 9 release radar. Note, in jdk 9 Graal is used only in AOT tool and is not affected by this problem. But we will fix it in 9 update release so that Graal from Oracle Labs can run with JDK 9.
29-06-2017
We are already at the late stage of JDK 9 release. How urgent this? Can you wait JDK 9 update release and fix it in 10 now?
29-06-2017
That approach seems reasonable to me.
23-06-2017
The [^CollectMBeanFromJVMCI.diff] contains a sketch of possible solution. It opens up the {{sun.management.spi}} package to {{jdk.internal.vm.ci}} module which registers its own {{PlatformMBeanProvider}} - I have verified that this code is called once **VisualVM** connects to the java process. Then it is about obtaining the right bean from the actual JVMCI compiler. I did that by extending {{HotSpotJVMCICompilerFactory}} - I am not very happy about that - suggestions of doing it in a better way are welcomed.
23-06-2017