RFR: 6313903: Thread.sleep(3) might wake up immediately on windows

[David Holmes]

Bug: https://bugs.openjdk.java.net/browse/JDK-6313903
webrev: http://cr.openjdk.java.net/~dholmes/6313903/webrev/

This is a fix to a very long term problem on Windows that really should 
have been fixed many years ago: the Windows timed-wait routines can 
return early by up to a clock tick** (which itself could be as long as 
16ms). The fix for Thread.sleep is to track the elapsed time (via 
nanoTime) and simply adjust and repeat the sleep if we were going to 
return earlier than requested. This is the same as what we have been 
doing on non-Windows for many years.

** whether or not you observe this seems highly dependent on hardware - 
see bug report for observed behaviours.

The additional motivation for fixing this now is to reduce the amount of 
platform specific sleep/interrupt code and to allow changes to the 
shared interrupt code. There are some additional RFE's in the pipeline 
for that.

This fix does the following:
- moves the os_posix.cpp os::sleep implementation to os.cpp to be shared 
by all platforms and deletes the os_windows.cpp os::sleep implementation
   - there are some additional comments added and the JavaThread 
assertion is moved to the head of the "interruptible" code path
- updates os_windows.cpp in these additional ways:
   - updates the commentary about creating the interrupt_event (which is 
now only used by JDK library code for use by Process.waitFor)
   - updates os::interrupt to also unpark the _SleepEvent
   - moves the use of the HighResolutionInterval utility class from the 
os::sleep code to the PlatformEvent::park code, so that sleep on Windows 
will still make adjustments to the clock tick if needed (it also means 
that Object.wait() calls will now make the same adjustments**).

** This is a change behaviour but I'm not concerned about there being 
any adverse effects from this. On many systems the code will have no 
affect as the system will be using the 1ms clock tick all the time 
anyway (e.g. my laptops do this). On systems with e.g. 15ms tick, what 
you will now see is Object.wait returning on time rather than much later 
than requested e.g. before this fix a timed-wait of 1ms returned in 
15.14ms, but after the fix it was 2.3ms. (Note that this observation 
seems contrary to the general statement that windows timed-wait event 
operations can return early by up to a clock tick - as I said it seems 
highly hardware dependent.)

Testing: tiers 1-3
          custom testing to look at sleep and wait times, as per bug report.

Thanks,
David
-----