JDK-8187490 : HotSpotGraalMBean should be moved to Graal management module
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-09-13
  • Updated: 2018-04-26
  • Resolved: 2018-04-18
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 11
11 b11Fixed
Related Reports
Relates :  
JDK-8182701 - Modify JVMCI to allow Graal Compiler to expose platform MBean
Relates :  
JDK-8201795 - jdk/modules/etc/UpgradeableModules.java fails non-upgradeable modules are not hashed: jdk.internal.vm.compiler.management
Description
JDK-8182701 proposes to add a Graal management module (jdk.internal.vm.compiler.management) to expose the management interface of Graal compiler.

This issue tracks the follow-on refactoring to do the proper modularization, moving HotSpotGraalMBean to jdk.internal.vm.compiler.management while exporting the access to the internal API to it.
Comments
The GitHib Graal changes related to this issue are https://github.com/oracle/graal/commit/48b6b625b43b09f451dac5d82ca87569a1a01c61
18-04-2018
I've created a preliminary patch at http://cr.openjdk.java.net/~dnsimon/8187490/ that makes jdk.internal.vm.compiler.management upgradeable and removes the defunct GraalMBeans.java source that uses Graal API that is being removed.
11-04-2018
Given that jdk.internal.vm.compiler.management is a non-upgradeable module, it's impossible to develop and test a change in GitHub Graal where jdk.internal.vm.compiler is modified to use a service provider in jdk.internal.vm.compiler.management: Error occurred during initialization of boot layer java.lang.module.FindException: Hash of jdk.internal.vm.compiler.management (fd62135907afa1d423e835e6d860c13e10e5366462ae01f74152d7fe3c60094d) differs to expected hash (4ecea26a71cd2d7cacf07ebdd0edda4d182baa5e2a62fea9b94523bfcf376dc7) recorded in java.base Since Graal is developed and tested on GitHub, this is a blocker. The only solution I can see is to make jdk.internal.vm.compiler.management upgradeable. [~alanb] has raised the concerns about this: "If a module is upgradeable then it makes it easy to impersonate. In this case, I can create my own module named jdk.internal.vm.compiler.management, deploy it on the upgrade module path, and I get access to sun.management.spi so I can register my own "platform" MXBeans. It's probably not a major concern but gives you an idea why so few modules are upgradeable. Ideally none of the core modules would export internal packages to upgradeable modules." However, deploying upgraded modules is a command line (only) capability as far as I know. If one has access to the command line, much more dangerous things are possible. Also if upgradeability is not transitive, then you are effectively locking the API of an upgradeable module. For example, jdk.internal.vm.compiler can never change the parts depended on by jdk.internal.vm.compiler.management if the latter cannot be upgraded. As such, I propose that jdk.internal.vm.compiler.management be made upgradeable.
11-04-2018