RFR(L): 8056049: getProcessCpuLoad() stops working in one process when a different process exits

Christian Tornqvist christian.tornqvist at oracle.com
Mon Nov 3 16:58:12 UTC 2014


Hi Markus,

Thanks for the detailed walkthrough, this looks really good. 

Thanks,
Christian

-----Original Message-----
From: hotspot-runtime-dev
[mailto:hotspot-runtime-dev-bounces at openjdk.java.net] On Behalf Of Markus
Grönlund
Sent: Wednesday, October 29, 2014 5:23 AM
To: hotspot-runtime-dev at openjdk.java.net
Subject: FW: RFR(L): 8056049: getProcessCpuLoad() stops working in one
process when a different process exits

Hi,

Trying my luck with Runtime as well - any Windows people that might be able
to do a review?

Bug: https://bugs.openjdk.java.net/browse/JDK-8056049

Webrev: http://cr.openjdk.java.net/~mgronlun/8056049/webrev01/


Thanks in advance
Markus


-----Original Message-----
From: Markus Grönlund 
Sent: den 24 oktober 2014 12:04
To: core-libs-dev Libs
Subject: FW: RFR(L): 8056049: getProcessCpuLoad() stops working in one
process when a different process exits

Also sending this to core-libs.

 

Thanks in advance

Markus

 

From: Markus Grönlund 
Sent: den 22 oktober 2014 11:44
To: serviceability-dev at openjdk.java.net; jmx-dev at openjdk.java.net
Subject: RFR(L): 8056049: getProcessCpuLoad() stops working in one process
when a different process exits

 

Greetings,

 

Kindly asking for reviews for the following changeset.

 

Bug: https://bugs.openjdk.java.net/browse/JDK-8056049 

Webrev: http://cr.openjdk.java.net/~mgronlun/8056049/webrev01/ 

 

Description:

 

The issue is  Windows specific. And the problem relates to using the
Performance Data Helper API (PDH), more specifically how to use the
"Process" PDH object in PDH queries:

 

// code comment extract

 

/*

* Working against the Process object and it's related counters is inherently
problematic

* when using the PDH API:

*

* For PDH, a process is not primarily identified by it's process id,

* but with a sequential number, for example \Process(java#0),
\Process(java#1), ....

* The really bad part is that this list is reset as soon as one process
exits:

* If \Process(java#1) exits, \Process(java#3) now becomes \Process(java#2)
etc.

*

* The PDH query api requires a process identifier to be submitted when
registering

* a query, but as soon as the list resets, the query is invalidated (since
the name

* changed).

*

* Solution:

* The #number identifier for a Process query can only decrease after process
creation.

*

* Therefore we create an array of counter queries for all process object
instances

* up to and including ourselves:

*

* Ex. we come in as third process instance (java#2), we then create and
register

* queries for the following Process object instances:

* java#0, java#1, java#2

*

* currentQueryIndexForProcess() keeps track of the current "correct" query

* (in order to keep this index valid when the list resets from underneath,

* ensure to call getCurrentQueryIndexForProcess() before every query
involving

* Process object instance data).

*/

 

I have already fixed this in the VM as of
https://bugs.openjdk.java.net/browse/JDK-8019921 

 

In the process of fixing this issue now in the JDK, I realized that the
previous implementation of using PDH in the JDK was a bit convoluted -
especially if you would like to reuse functionality / add new counters.

 

Therefore this change also includes an overall rewrite of the how the JDK
will interface with the PDH library, a rewrite of which (hopefully) improves
both readability and extensibility.

 

I can do a code walkthrough live if anyone is interested to know the exact
details of this change.

 

Testing completed : Testset SVC (includes jdk_instrument, jdk_management,
jdk_jmx, jdk_jdi)

 

Thanks in advance

Markus

 



More information about the hotspot-runtime-dev mailing list