JDK-8152206 : Simplify jvmstat modules
  • Type: Bug
  • Component: core-svc
  • Affected Version: 9
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-18
  • Updated: 2017-02-22
  • Resolved: 2017-01-19
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 JDK 9
10Fixed 9 b156Fixed
Related Reports
Relates :  
JDK-8175326 - JMap timeout after java.lang.reflect.InaccessibleObjectException
Relates :  
JDK-8043138 - Attach API should not require jvmstat rmi protocol
Sub Tasks
JDK-8154905 :  
Rename jdk.jvmstat.rmi to jdk.jstatd - Resolved
Description
As of 2016-03-18, the JDK module graph contains modules called jdk.jvmstat and jdk.jvmstat.rmi.

The names jdk.jvmstat and jdk.jvmstat.rmi imply "API for accessing JVM stats locally" and "API for accessing JVM stats remotely", but neither is true. There's no usable API in the former module (all its exports are qualified to other jdk.* modules) and there's only a tool in the latter module. Our convention for JDK module naming suggests "internal" in the former's name and "jstatd" in the latter's name.

Furthermore, the jdk.jvmstat module is dominated(*) in the module graph by the jdk.attach module. This suggests that rather than renaming jdk.jvmstat to jdk.internal.jvmstat, it should simply be folded into jdk.attach. jdk.attach would gain some qualified exports to its direct consumers.

(*) Truthfully, there is one module which requires jdk.jvmstat without going through jdk.attach: jdk.jvmstat.rmi. Happily, there is no conceptual or technical problem with jdk.jvmstat.rmi depending on an enriched jdk.attach.

Proposal:
- Merge jdk.jvmstat into jdk.attach.
- Rename jdk.jvmstat.rmi to jdk.jstatd, and make it require jdk.attach.
Comments
This shows the proposal to move jdk.jvmstat to jdk.jcmd and jdk.attach does its own VM discovery: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8152206/webrev.00/ This patch adds two new classes in jdk.base/jdk.internal.perf to read performance counters since jdk.attach depends on the performance counter storing the command-line arguments of the running JVM as a display name. java.base/jdk.internal.perf package provides internal APIs for jdk.jvmstat to get the perfdata buffer and also for JDK to write counters into the perfdata buffer. The new classes in the patch provides internal API to read perf counters from a perfdata buffer. This is a small code duplication between java.base and jdk.jcmd (if sun.jvmstat.** packages are moved to jdk.jcmd). Future refactoring can be done in the future to remove the code duplication. An alternative is to simply rename jdk.jvmstat as jdk.internal.stat (or other appropriate name) in JDK 9. Then remove jdk.internal.stat when the refactoring is properly done in a future release.
06-01-2017
[~ctornqvi] We have a plan to resolve this issue in Jan 2017. It's not a new feature, it is instead most about addressing an implementation dependency issue.
30-12-2016
[~mchung] Any update on this? FC is in 3 days.
19-12-2016
The jvmstat perf counters are the internal functionality for serviceability tools to use and jdk.jcmd is the home for all these serviceability tools. It is also used by the attach API to list the hotspot VMs on the local system. One proposal is to define a new service type in jdk.attach say com.sun.tools.attach.spi.VirtualMachineFinder. Merge jdk.jvmstat with jdk.jcmd and also jdk.jcmd to provide an implementation to com.sun.tools.attach.spi.VirtualMachineFinder to list the hotspot VMs on the local system.
13-12-2016
We are re-examining these modules for JDK 9. It's on the Jigsaw M4 list. Please leave the fixVersion at 9 for now.
31-05-2016
1. The more service-oriented an API can be, the less need for a dedicated module for its main provider. If jdk.attach's dependency on jdk.jvmstat's API can be reformulated as a service interface exported by jdk.attach and a service implementation lurking in jdk.FOO, then does it matter if FOO is 'attach' rather than 'jvmstat' ? 2. It's one thing to use the jdk.internal prefix when code from outside the JDK is brought wholesale into a dedicated JDK module. It's another thing to use the jdk.internal prefix for a "true" JDK module -- jdk.internal.jvmstat would be the only example.
21-03-2016
The attach API and jvmstat can be loosely considered to be "infrastructure" for troubleshooting tools. They are unrelated though. The only reason that the jdk.attach module depends on jdk.jvmstat is because the HotSpot implementation of AttachProvider.listVirtualMachines uses jvmstat to find hotspot VMs on the local system. We could refactor this to use services (we just need to figure out where to put the service type). The reason that the jdk.attach module exports sun.tools.attach to to jdk.jcmd is because jdk.jcmd provides the tools in this module provide several HotSpot-specific commands that require getting at the HotSpot attach provider.
19-03-2016