Request for reviews (update)(S): 6863420: os::javaTimeNanos() go backward on Solaris x86]

[Vladimir Kozlov]

David Holmes - Sun Microsystems wrote:
> Sorry for the blast from the past ...
> 
> On 07/25/09 05:39, Paul Hohensee wrote:
>> Nice. :)
>>
>> Sometime we should update the other os platforms with their own 
>> implementations.
>> Nop for now of course.
> 
> So I missed this back in July ... why didn't we define this for the 
> other OS as needed? I assume Linux x86 has exactly the same problem.

I am not Linux expert but based on comments in os_linux.cpp in
os::Linux::clock_init() newest kernels support monotonic clock
so we don't need to cache timer for them.

Vladimir

> backporting this to JRTS and duplicating the caching code on Linux (for 
> uniformity) and I need Atomic::load on Linux to do that :(
> 
> David
> 
>> Paul
>>
>> Vladimir Kozlov wrote:
>>> I updated the fix to use Atomic::load() always as David H. suggested.
>>>
>>> http://cr.openjdk.java.net/~kvn/6863420/webrev.01
>>>
>>> Fixed 6863420: os::javaTimeNanos() go backward on Solaris x86
>>>
>>> Problem:
>>> The problem is non atomic load from max_hrtime in getTimeNanos()
>>> on platforms where long is kept in 2 32-bit register.
>>> The loaded value could be invalid (> current time) since registers
>>> are loaded separately and store could happened in between.
>>> It could be returned as result if it is greater then current time.
>>> And if the next call getTimeNanos() returns the correct time
>>> it will be less then previous result.
>>>
>>> Solution:
>>> Use new atomic long load method Atomic::load() which uses
>>> FPU to move long value atomically on 32-bit x86 or
>>> simply returns *src in other cases.
>>>
>>> Added the regression test which shows the problem.
>>>
>>> Reviewed by:
>>>
>>> Fix verified (y/n): y, regression test
>>>
>>> Other testing:
>>> JPRT, ScaleHarness(6784100)
>>>