RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again (original) (raw)
Brent Christian brent.christian at oracle.com
Mon Apr 14 17:22:41 UTC 2014
- Previous message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Next message: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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: RFR [8038982]: java/lang/ref/EarlyTimeout.java failed again
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]