RFR 9: 8098852 : java/lang/ProcessHandle/InfoTest.java failed: total cpu time

[Roger Riggs]

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