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

[Ivan Gerasimov]

Thanks Chris!

It's very similar, though still different.

ReferenceQueue.remove(timeout) makes sure the timeout has fully elapsed, 
using System.nanoTime().
Thus the test failure only indicates that nested time intervals measured 
with nanoTime() and currentTimeMillis() can be inconsistent: The inner 
interval turns out to be bigger than the outer. But the inner interval 
is guaranteed to be not less than the timeout specified.

Sincerely yours,
Ivan

On 14.04.2014 19:35, Chris Hegarty wrote:
> Are you by any chance running on a VM? We have seen issues like this 
> before, see
>   https://bugs.openjdk.java.net/browse/JDK-7148829
>     ( as of yet still unresolved)
>
> -Chris.
>
> On 14/04/14 14:21, 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
>
>