RFR (S): 7117303: VM uses non-monotonic time source and complains that it is non-monotonic

[David Holmes]

John,

monaco is Oracle internal, you need to link to bugs.sun.com:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7117303

Cheers,
David

On 13/12/2011 7:36 AM, Charles K Pepperdine wrote:
> Hi John,
>
> Thanks, that one fails also.
>
> Regards,
> Kirk
>
> On Dec 12, 2011, at 8:48 PM, John Cuthbertson wrote:
>
>> Hi Kirk,
>>
>> Can you please try monaco.us.oracle.com <http://monaco.us.oracle.com>?
>> I believe the link is supplied by the webrev tool automatically when
>> it sees the CR# in the mercurial queue patch. It could be that my path
>> references an old version.
>>
>> Thanks,
>>
>> JohnC
>>
>> On 12/09/11 23:59, Charles K Pepperdine wrote:
>>> Hi John,
>>>
>>> The linkhttp://monaco.sfbay.sun.com/detail.jsp?cr=7117303  is unreachable.
>>>
>>> Regards,
>>> Kirk
>>>
>>>
>>> On Dec 9, 2011, at 8:30 PM, John Cuthbertson wrote:
>>>
>>>
>>>> Hi Everyone,
>>>>
>>>> I have updated the comments based upon feedback from David Holmes. A new webrev can be found at:http://cr.openjdk.java.net/~johnc/7117303/webrev.1/
>>>>
>>>> Thanks,
>>>>
>>>> JohnC
>>>>
>>>> On 12/7/2011 9:59 AM, John Cuthbertson wrote:
>>>>
>>>>> Hi Everyone,
>>>>>
>>>>> Can I have a couple of volunteers review the changes for this CR? The webrev can be found at:http://cr.openjdk.java.net/~johnc/7117303/webrev.0/.
>>>>>
>>>>> Summary:
>>>>> I replaced the calls to os::javaTimeMillis() in the GC where we expect monotonicity with calls os::javaTimeNanos(), converting the result to milliseconds. os::javaTimeNanos(), at least on some configurations, does guarantee monotonicity and so is a better alternative. The changes in the os_<*>  files are to make use of the named conversion constants I added/moved to globalDefinitions.hpp - we seemed to have multiple names for the same two constants.
>>>>>
>>>>> Testing: GC test suite on solaris and Linux, NSK tests on solaris, and jprt.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> JohnC
>>>>>
>>>
>>>
>>
>