United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8019921 No CPULoad-events when recording a GlassFish instance
JDK-8019921 : No CPULoad-events when recording a GlassFish instance

Details
Type:
Bug
Submit Date:
2013-07-04
Status:
Closed
Updated Date:
2013-09-28
Project Name:
JDK
Resolved Date:
2013-07-10
Component:
hotspot
OS:
Sub-Component:
jfr
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
7u40
Fixed Versions:
hs24 (b53)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
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.
                                    

Comments
Fix in progress
                                     
2013-07-05
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
                                     
2013-07-05
I have verified that Markus' fix solves the issue. JMC really want this fix in 7u40.
                                     
2013-07-05
Need SQE-OK before this can be approved.
                                     
2013-07-05
SQE OK

                                     
2013-07-08
See David Lindholm's comment.
                                     
2013-08-14
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
                                     
2013-07-05



Hardware and Software, Engineered to Work Together