RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed: total cpu time
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/ Issue: https://bugs.openjdk.java.net/browse/JDK-8098852 Thanks, Roger
Hi Roger, Generally looks okay; a few comments and suggestions 114 long cpulooptime = 100; // 100 ms How about cpuLoopTime instead? Same comment for the other variables that don't follow camel-case conventions. 284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) { Is it correct to multiply cpu-millis by 1e6 rather than 1e3? -Joe On 7/7/2015 11:52 AM, Roger Riggs wrote:
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
Issue: https://bugs.openjdk.java.net/browse/JDK-8098852
Thanks, Roger
Hi Joe, Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/ On 7/7/2015 7:59 PM, joe darcy wrote:
Hi Roger,
Generally looks okay; a few comments and suggestions
114 long cpulooptime = 100; // 100 ms
How about
cpuLoopTime ok
instead? Same comment for the other variables that don't follow camel-case conventions. I fixed a few others too.
284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) {
Is it correct to multiply cpu-millis by 1e6 rather than 1e3? Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
Thanks, Roger
-Joe
On 7/7/2015 11:52 AM, Roger Riggs wrote:
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
Issue: https://bugs.openjdk.java.net/browse/JDK-8098852
Thanks, Roger
Hi Roger, A few comments on the updated version. 284 long cpuMillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpuMillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) { 287 // burn the cpu until the time is up Are there interger overflow issues in adding to the result of getCpuTime()? Should the time values be a function of the timeout factor the test is running under? If the answer to both of these is "no," then I think this is okay as-is. Thanks, -Joe On 7/8/2015 1:07 PM, Roger Riggs wrote:
Hi Joe,
Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
On 7/7/2015 7:59 PM, joe darcy wrote:
Hi Roger,
Generally looks okay; a few comments and suggestions
114 long cpulooptime = 100; // 100 ms
How about
cpuLoopTime ok
instead? Same comment for the other variables that don't follow camel-case conventions. I fixed a few others too.
284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) {
Is it correct to multiply cpu-millis by 1e6 rather than 1e3? Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
Thanks, Roger
-Joe
On 7/7/2015 11:52 AM, Roger Riggs wrote:
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
Issue: https://bugs.openjdk.java.net/browse/JDK-8098852
Thanks, Roger
Hi Joe, The cputime loop is designed to run up the cputime of a child process a specific amount so that the parent can verify that the cputime information reported about the child is correct. No issues on either point, the range long in nanoseconds is more than sufficient for the length of time this test is running. The test only asks for the child to use 100ms. Thanks, Roger On 7/8/2015 5:05 PM, joe darcy wrote:
Hi Roger,
A few comments on the updated version.
284 long cpuMillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpuMillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) { 287 // burn the cpu until the time is up
Are there interger overflow issues in adding to the result of getCpuTime()?
Should the time values be a function of the timeout factor the test is running under?
If the answer to both of these is "no," then I think this is okay as-is.
Thanks,
-Joe
On 7/8/2015 1:07 PM, Roger Riggs wrote:
Hi Joe,
Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
On 7/7/2015 7:59 PM, joe darcy wrote:
Hi Roger,
Generally looks okay; a few comments and suggestions
114 long cpulooptime = 100; // 100 ms
How about
cpuLoopTime ok
instead? Same comment for the other variables that don't follow camel-case conventions. I fixed a few others too.
284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) {
Is it correct to multiply cpu-millis by 1e6 rather than 1e3? Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
Thanks, Roger
-Joe
On 7/7/2015 11:52 AM, Roger Riggs wrote:
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
Issue: https://bugs.openjdk.java.net/browse/JDK-8098852
Thanks, Roger
Hi Roger, Le me be more explicit, is getCpuTime() something that gets normalized to zero-ish at the start of each run or is it just a shapshot of some nano-second granularity counter? If it is the latter, it is possible that the counter value is negative or near the long overflow threshold. -Joe On 7/8/2015 2:11 PM, Roger Riggs wrote:
Hi Joe,
The cputime loop is designed to run up the cputime of a child process a specific amount so that the parent can verify that the cputime information reported about the child is correct.
No issues on either point, the range long in nanoseconds is more than sufficient for the length of time this test is running. The test only asks for the child to use 100ms.
Thanks, Roger
On 7/8/2015 5:05 PM, joe darcy wrote:
Hi Roger,
A few comments on the updated version.
284 long cpuMillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpuMillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) { 287 // burn the cpu until the time is up
Are there interger overflow issues in adding to the result of getCpuTime()?
Should the time values be a function of the timeout factor the test is running under?
If the answer to both of these is "no," then I think this is okay as-is.
Thanks,
-Joe
On 7/8/2015 1:07 PM, Roger Riggs wrote:
Hi Joe,
Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
On 7/7/2015 7:59 PM, joe darcy wrote:
Hi Roger,
Generally looks okay; a few comments and suggestions
114 long cpulooptime = 100; // 100 ms
How about
cpuLoopTime ok
instead? Same comment for the other variables that don't follow camel-case conventions. I fixed a few others too.
284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) {
Is it correct to multiply cpu-millis by 1e6 rather than 1e3? Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
Thanks, Roger
-Joe
On 7/7/2015 11:52 AM, Roger Riggs wrote:
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
Issue: https://bugs.openjdk.java.net/browse/JDK-8098852
Thanks, Roger
Hi Joe, The value is from the operating system as it keeps track of cputime for each process as reported by java.lang.management. It starts at zero for each process started. static long getCpuTime() { OperatingSystemMXBean osMbean = (OperatingSystemMXBean)ManagementFactory.getOperatingSystemMXBean(); return osMbean.getProcessCpuTime(); } Roger On 7/8/15 8:59 PM, Joseph D. Darcy wrote:
Hi Roger,
Le me be more explicit, is getCpuTime() something that gets normalized to zero-ish at the start of each run or is it just a shapshot of some nano-second granularity counter? If it is the latter, it is possible that the counter value is negative or near the long overflow threshold.
-Joe
On 7/8/2015 2:11 PM, Roger Riggs wrote:
Hi Joe,
The cputime loop is designed to run up the cputime of a child process a specific amount so that the parent can verify that the cputime information reported about the child is correct.
No issues on either point, the range long in nanoseconds is more than sufficient for the length of time this test is running. The test only asks for the child to use 100ms.
Thanks, Roger
On 7/8/2015 5:05 PM, joe darcy wrote:
Hi Roger,
A few comments on the updated version.
284 long cpuMillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpuMillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) { 287 // burn the cpu until the time is up
Are there interger overflow issues in adding to the result of getCpuTime()?
Should the time values be a function of the timeout factor the test is running under?
If the answer to both of these is "no," then I think this is okay as-is.
Thanks,
-Joe
On 7/8/2015 1:07 PM, Roger Riggs wrote:
Hi Joe,
Updated the webrev in place. http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
On 7/7/2015 7:59 PM, joe darcy wrote:
Hi Roger,
Generally looks okay; a few comments and suggestions
114 long cpulooptime = 100; // 100 ms
How about
cpuLoopTime ok
instead? Same comment for the other variables that don't follow camel-case conventions. I fixed a few others too.
284 long cpumillis = Long.valueOf(args[nextArg++]); 285 long cpuTarget = getCpuTime() + cpumillis * 1_000_000L; 286 while (getCpuTime() < cpuTarget) {
Is it correct to multiply cpu-millis by 1e6 rather than 1e3? Yes, CpuTime is in nanos = millis * 1000 (micros) * 1000
Thanks, Roger
-Joe
On 7/7/2015 11:52 AM, Roger Riggs wrote:
Please review this ProcessHandle test change to cleanup intermittent failures. The cpuloop timing uses the cputime of the spawned process and the test runs fewer iterations and relaxes the threshold.
Webrev: http://cr.openjdk.java.net/~rriggs/webrev-info-8098852/
Issue: https://bugs.openjdk.java.net/browse/JDK-8098852
Thanks, Roger
participants (3)
-
joe darcy
-
Joseph D. Darcy
-
Roger Riggs