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

[Charles K Pepperdine]

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? 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 link http://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
>>>>       
>> 
>>   
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20111212/e7a7a17a/attachment.html