RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again (original) (raw)
Ivan Gerasimov ivan.gerasimov at oracle.com
Mon Apr 14 18:31:14 UTC 2014
- Previous message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Next message: Covariant overrides on the Buffer Hierachy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Next message: Covariant overrides on the Buffer Hierachy
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]