JDK-8189091 : MBean access to the PID
  • Type: CSR
  • Component: core-svc
  • Sub-Component: java.lang.management
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 10
  • Submitted: 2017-10-10
  • Updated: 2017-11-22
  • Resolved: 2017-11-06
Related Reports
CSR :  
JDK-8044122 - MBean access to the PID
Relates :  
JDK-8176314 - JMX: RuntimeMXBean support for monitoring modular runtime information
Description
Summary
-------

Introduced new API `java.lang.management.RuntimeMXBean.getPid` to get process ID of running Java virtual machine.

Problem
-------

The platform MBean does not provide any API to get the process ID of a running JVM.   Some JMX tools rely on the hotspot implementation of `RuntimeMXBean::getName` which returns < pid \>@< hostname \>.

Solution
--------

Introduced new API `java.lang.management.RuntimeMXBean.getPid`, so that JMX tools can directly get process ID instead of relying on the implementation detail,  `RuntimeMXBean#getName().split("@")[0]`.

Specification
-------------

 

      --- old/src/java.management/share/classes/java/lang/management/RuntimeMXBean.java	2017-11-02 15:03:57.177210581 +0530
    +++ new/src/java.management/share/classes/java/lang/management/RuntimeMXBean.java	2017-11-02 15:03:56.993210581 +0530
    @@ -25,6 +25,9 @@
     
     package java.lang.management;
     
    +import java.security.AccessController;
    +import java.security.PrivilegedAction;
    +
     /**
      * The management interface for the runtime system of
      * the Java virtual machine.
    @@ -61,6 +64,22 @@
      */
     public interface RuntimeMXBean extends PlatformManagedObject {
         /**
    +     * Returns the {@linkplain ProcessHandle#pid process ID} representing
    +     * the running Java virtual machine.
    +     *
    +     * @implSpec The default implementation returns {@link ProcessHandle#pid process ID}
    +     * of the {@linkplain ProcessHandle#current current process}.
    +     *
    +     * @return the process ID representing the running Java virtual machine.
    +     *
    +     * @since 10
    +     */
    +    public default long getPid() {
    +        return AccessController.doPrivileged((PrivilegedAction<Long>)
    +                () -> ProcessHandle.current().pid());
    +    }
    +
    +    /**
          * Returns the name representing the running Java virtual machine.
          * The returned name string can be any arbitrary string and
          * a Java virtual machine implementation can choose
Comments
JDK-8176314 is the RFE for extending monitoring for the modular runtime.
06-11-2017
Sorry, I should have stated "Should RuntimeMXBean be updated t handle modules?" since it has methods like "getBootClassPath" and "getLibraryPath" but no methods defined with respect to modules.
06-11-2017
Several existing methods in RuntimeMXBean could be changed into default methods e.g. getClassPath, getSpecName, getSpecVendor etc. It seems a nice but low priority RFE.
06-11-2017
What aspect of ProcessHandle could take advantage of knowledge about modules?
06-11-2017
Moving the revised request to approved. Please answer the previously asked questions: Could the existing interface methods could be changed to be default methods that had the implementation in question? Should ProcessHandle be updated to handle modules?
06-11-2017
Joe's suggestion on the default implementation is a very good one. This default implementation can provide the actual implementation (ProcessHandle.current().pid()). I agree to make this change.
01-11-2017
I Agree, RuntimeMXBean.getPid() can make the code of the default method the real implementation for the method. I will send out the change for review and update the CSR.
01-11-2017
The spec for the RuntimeMXBean interface basically says "there is only one implementation of this interface." If that is true, then independent of this change, the existing methods which basically spell out what there compliant method bodies must be could be replaced by those actual method bodies as default method and the method implementations removed from the single implementation of the interface. If there is only one implementation of the interface that we care about, migration isn't much of a problem. Throwing an UOE when a default method is added to an interface is often a good choice, but this isn't an interface with a usual implementation pattern. Therefore, I'm suggesting the new method in RuntimeMXBean take advantage of the atypical usage patterns of this interface by making the code of the default method the real implementation for the method. (At the very least, the pid method should be @link'ed or @see'ed from the javadoc.)
01-11-2017
This method is made default just to ease the migration, not because it's implementation is optional. All existing methods of RuntimeMXBean should be implemented by JDK implementation. Operationally RuntimeMXBean.getPid() is same as calling ProcessHandle.current().pid() Remote access is one advantage that we get with RuntimeMXBean.getPid().
01-11-2017
From the specification for RuntimeMXBean "A Java virtual machine has a single instance of the implementation class of this interface." Many methods of RuntimeMXBean are specified to be equivalent to calling other methods. Could the existing interface methods could be changed to be default methods that had the implementation in question? For this CSR, it would seem preferable given the particular semantics of this class, to operationally define RuntimeMXBean.getPid() in terms of ProcessHandle.pid or similar. Is that possible? Making the request as pended while the discussion is ongoing. PS Should ProcessHandle be updated to handle modules?
01-11-2017