Request for review: 6888526 Linux getCurrentThreadCpuTime is drastically slower than Windows

[Andrew Haley]

On 07/08/2010 05:34 AM, David Holmes wrote:
> Daniel D. Daugherty said the following on 07/08/10 09:03:
>> The official configurations are listed here:
>>
>> http://java.sun.com/javase/6/webnotes/install/system-configurations.html
>>
>> but I don't know how to translate the various Linux versions
>> into something that would help resolve this issue.
> 
> The functionality should be supported in all 2.6.16+ kernels, and
> potentially supported in 2.6.10+ with appropriate patches - but, like
> Dan, I have no way to know what kernel versions the supported Linux
> distros actually have.

I can speak for the Red Hat distros: RHEL 4, which I tested, has the
2.6.9 kernel.  It's the most recent Red Hat distro that does not
support the fast timers.

> Because we dynamically check for the supported functionality this should
> not cause a problem as we will fall-back to using "slow clocks" if they
> aren't present.
>
> I agree it is time to change this default, but note that we need to
> mention this in the release notes somewhere and, more importantly, we
> need to ensure there is extensive testing here because we may be using
> OS functionality that has hitherto been unused (or little used) and we
> may encounter bugs in that functionality (bugs in the OS? surely not! ;-))
> 
> Further, as Dan mentions, this would then affect Java 6 updates and that
> is not allowed (without additional 'paperwork') so we'd have to augment
> Arguments::parse_each_vm_init_arg in arguments.cpp by adding to the end:
> 
>  if (JDK_Version::current().compare_major(6) <= 0 &&
>       FLAG_IS_DEFAULT(UseLinuxPosixThreadCPUClocks)) {
>     FLAG_SET_DEFAULT(UseLinuxPosixThreadCPUClocks, false);
>   }
> 
> this forces the flag to false in Java 6 unless it has been set explicitly.

OK, I will make that change and test and resubmit my webrev
accordingly.  I'll also make sure it does the Right Thing with JDK 6.

Andrew.