RFR(xs): 8150843: [windows] os::getTimesSecs() returns negative values for kernel, user times

David Holmes david.holmes at oracle.com
Tue Mar 1 07:32:10 UTC 2016


On 1/03/2016 5:18 PM, Thomas Stüfe wrote:
> Hi David,
>
> On Mon, Feb 29, 2016 at 10:12 PM, David Holmes <david.holmes at oracle.com
> <mailto:david.holmes at oracle.com>> wrote:
>
>     Hi Thomas,
>
>     On 1/03/2016 3:14 AM, Thomas Stüfe wrote:
>
>         Hi all,
>
>         please review and sponsor this small fix.
>
>         It fixes an error in os::getTimesSecs() for windows which causes the
>         numbers for kernel- and usertime to be off. This does not cause
>         an error,
>         because the sole user of this function, the TraceCpuTime class,
>         uses this
>         function to measure twice and calculate the deltas.
>
>         I still think it is a good idea to fix this bug - with the fix, the
>         returned values are based on the process start and will be the
>         same for all
>         platforms (the *nix platforms use times()).
>
>         bug report: https://bugs.openjdk.java.net/browse/JDK-8150843
>         webrev:
>         http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.00/webrev/
>
>
>     So the error is that kernel and user times are treated as-if they
>     were absolute times - which they are not.
>
>     I still find this somewhat confusing though:
>
>       955     jlong user_millis = jlong_from(user_time.dwHighDateTime,
>     user_time.dwLowDateTime);
>       956     jlong system_millis =
>     jlong_from(kernel_time.dwHighDateTime, kernel_time.dwLowDateTime);
>
>
>     as neither of those calculations will give a value that represents
>     milliseconds. I'd rather see the adjustment to millis occur above
>     rather than here:
>
>     958     *process_user_time = ((double) user_millis) / ((double) (10
>     * MICROUNITS));
>       959     *process_system_time = ((double) system_millis) /
>     ((double) (10 * MICROUNITS));
>
>
> You are right, this is confusing. But if I do the division with a jlong,
> I loose precision (the code before did too). So, I do now the conversion
> in one step:
>
> http://cr.openjdk.java.net/~stuefe/webrevs/8150843-windows-osGetTimesSecs/webrev.01/webrev/
>
> So, the new version not only returns values with the correct offset now,
> they are also more precise, which actually may benefit GC statistics.

Looks good. You're right those local temporaries are not needed. :)

Thanks,
David

> Kind Regards, Thomas
>
>
>     Thanks,
>     David
>
>
>
>         Kind Regards, Thomas
>
>


More information about the hotspot-runtime-dev mailing list