On the win32 platform, we try to implement high-resolution Thread.sleep() 
calls by using timeBeginPeriod(1)/timeEndPeriod(1) from the Windohs 
multimedia library, winmm.dll.  On some machines using that dll causes 
a 4-second delay in VM startup.  See 4653558 for details.  The solution 
that was tried there was backed out with 4712392 because many important 
customers have come to depend on high-resolution sleeps.

On some Windohs platforms, repeated changing the time period causes the 
Windohs time-of-day clock to run fast.  See 4500388 for details. The 
-XX:+ForceTimeHighResolution flag that was added for that seems to force 
low resolution time.

Further, because we use the default time period for sleeps that are 
multiples of 10ms, even if the default time period is not 10ms, the 
results of Thread.sleep() are not monotonic with the request argument.  

As an example of the last two problems, consider the output of 
a test ShortSleep100 program (attached):

    $ $deployed/4712392/bin/java     > -showversion -XX:+ForceTimeHighResolution ShortSleep100
    java version "1.4.1-rc"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b16)
    Java HotSpot(TM) Client VM (build 20020715.2049-4712392-compiler1-product, mixed mode)
     
    0       0.0   
    10      1563.0
    9       1562.0
    1       1563.0
    2       1562.0
    4       1563.0
    6       1562.0
    8       1563.0
    9       1562.0
    20      3125.0
    $ $deployed/4712392/bin/java     > -showversion -XX:-ForceTimeHighResolution ShortSleep100
    java version "1.4.1-rc"
    Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-rc-b16)
    Java HotSpot(TM) Client VM (build 20020715.2049-4712392-compiler1-product, mixed mode)
     
    0       0.0
    10      1562.0
    9       984.0
    1       204.0
    2       296.0
    4       485.0
    6       687.0
    8       875.0
    9       985.0
    20      3125.0    

Shouldn't the flag be named be -XX:+ForceHighResolutionTime to be more 
grammatically correct?

This whole section of code need to be thought out and cleaned up.

The specification for Thread.sleep() doesn't say anything about the 
resolution of the time period.  So we could just ignore the whole 
issue.  But high-resolution sleeps seem to be a distinguishing feature 
of our VM, so we are making a lot of people happy with it.

  xxxxx@xxxxx   2002-07-19

  xxxxx@xxxxx   2002-11-15
Workaround provided by   xxxxx@xxxxx  :

  We make sure we sleep for some number of milliseconds
  that is a multiple of 100. In our application we sleep
  from current time to the end of some interval. Since
  current time ends randomly between 0-9, most sleeps
  caused the problem. Now we round up to next 100 mSecs.

Ongoing issues concerning the use of high-resolution timers under win32 are being tracked through 5005837.

The default timer interrupt period on windows (at least NT4 onwards) is usually a nominal 10ms but can be  15ms on some hardware. The multi-media timers provide a nominal minimum interrupt period of 1ms, but use of this is not recommended (2ms should be the minimum) and the lowest period an application should rely on is 3ms - see:

http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx 

The use of these high-resolution timers in hotspot is currently determined by two things:
(a) If the -XX:ForceTimeHighResolution option is used then the timer interrupt period is set to 1ms when the VM loads, and is restored when the VM exits; otherwise
(b) If the sleep time is not a multiple of 10ms then the interrupt period is set to 1ms for the duration of the sleep and then restored

Note that simply using a 1ms period all the time is not a viable solution for many customers due to the 10-15x increase in the interrupt processing load. While faster hardware may negate this factor one day, it has not yet been established that this is the case.

The policy in (b) is not satisfactory for two reasons:
1. It is speculated that performing many changes to the interrupt period causes windows to lose track of the time and for the time-of-day clock to drift as a result. This appears to be a problem in Windows, but needs further investigation.
2. The 10ms value is inappropriate when the actual period is 15ms, and it leads to unexpected inconsistencies when a thread sleeps for values around a 10ms boundary. Further it is really the magnitude of the requested sleep time that is significant not its divisibility into 10ms pieces: a 10ms sleep requires high resolution, a 1001ms sleep does not.
Posted Date : 2006-05-09 00:01:52.0

Regarding the workaround described above, the problem we 
had was not with the clock running ahead, but with the 
sleeping process causing excessive system wide interrupts. 
When a thread sleeps, the number of milliseconds should be a 
multiple of at least 10 so sleep doesn't cause excessive 
system interrupts and affect all processes on the system.

4500388 is closed (but still a bug) so I'm voting for this one because it's related and still open.  Still seeing the clock run-ahead on 

(continued) ... on JDK1.4.2_06, _08 on Windows 2000 for certain specific hardware.