RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again

[Ivan Gerasimov]

Thank you Brent for the pointer!

I think that using nanoTime() is simpler in this situation.
We don't really have to use currentTimeMillis(), so no need to make it 
more reliable.

Sincerely yours,
Ivan

On 14.04.2014 21:22, Brent Christian wrote:
> Hi, Ivan
>
> This sounds like an issue we saw in FX a while ago with imprecise 
> timers on Windows.  If it is, you might check out:
>
> https://bugs.openjdk.java.net/browse/JDK-6435126
>
> It describes a workaround to enable higher-precision timing on Windows 
> (using a long-sleeping daemon thread).  That might be a third 
> alternative solution...
>
> -Brent
>
> On 4/14/14 6:21 AM, Ivan Gerasimov wrote:
>> Hello!
>>
>> The test EarlyTimeout.java failed again, now with message "elapsed time
>> 981 is less than timeout 1000."
>>
>> The root cause seems to be non-accurate time measurement in Windows:
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724397(v=vs.85).aspx 
>>
>>
>>
>> Because of this we can achieve this result:
>> long start1 = System.currentTimeMillis();
>> long start2 = System.nanoTime();
>> ~~~~~~~~
>> long elapsed2 = (System.nanoTime() - start2) / 1000000;
>> long elapsed1 = System.currentTimeMillis() - start1;
>>
>> assert elapsed2 < elapsed1; // can fail
>>
>>
>> There might be two ways to address the issue:
>> - add a tolerance > 15 ms, or
>> - use System.nanoTime() for the measurement.
>>
>> I did both.
>>
>> Would you please help review the test fix?
>>
>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8038982
>> WEBREV: http://cr.openjdk.java.net/~igerasim/8038982/0/webrev/
>>
>> Sincerely yours,
>> Ivan
>
>