JDK-8019921 : No CPULoad-events when recording a GlassFish instance
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jfr
  • Affected Version: 7u40
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-07-04
  • Updated: 2016-12-27
  • Resolved: 2013-07-10
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 7 JDK 8 Other
7u40Fixed 8Fixed hs24Fixed
Related Reports
Relates :  
When I do recordings on GlassFish, I never get any CPU-load-events, even though they are turned on. See the attached recording.

All other events seems to work fine. This is bad since CPU-load-information (one dial and one graph) are on the first page when opening a recording in Mission Control.
This fix seems still not not to work on 1.8.0_112-b15 as mentioned in JDK-8169704

See David Lindholm's comment.


Need SQE-OK before this can be approved.

I have verified that Markus' fix solves the issue. JMC really want this fix in 7u40.

7u40-critical-request-justification: The CPU load information is the "landing" page for JMC - without this change the experience will be real bad - its obvious something is not right. The solution will workaround the problematic PDH api on Windows to support querying the CPU load for the process even when other concurrent processes on the machine exits. Fix ready. Thanks Markus

This is specific to Windows, and it has to do with the way the list of performance monitor process object \Process(java#0) instances resets when other instances exits. For example: When I start java.exe, and there is already another java.exe process running, the list of Processes will look like: \Process(java#0) <<-- already running instance \Process(java#1) <<-- my instance Our code sets up a Pdh query against \Process(java#1) and all is well ...for a time. Then say the first java.exe(#0) process exits. This list is now reset so that the second java.exe instance (previous #1), now has the identifier (java#0). The problem is the PDH queries are registered for java#1, which means they are invalidated when this happens. The permutations of this really bad Win32 api could be even worse if there was another java#2 process running as welll: As the list "shifts", the first java#1 could still continue to use its registered query, however, now it will pull in performance data from the previous java#2 process, not its own data. Unbelievable that there is no way to specify the PID when register process specific counters - I will add a safety guard which add queries for all instances running, and do a check on every query what the current PID is mapped to which name (java#1, java#2 etc) to identify query of the correct process instance. Thanks for reporting this. Cheers Markus

Fix in progress