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.