The fix for 4500388 introduced the ForceTimeHighResolution switch to cause the VM to request a 1ms timer interrupt period at startup, and restore the timer period at shutdown, and consequently to disable the per-sleep changing of the timer period that would otherwise occur. This was applied to 1.3.1_04+, 1.4.0_02+, 5.0+ and 6.

However, the code to change the timer was placed in DllMain and at the time it is executed the command-line switches have not been processed and so ForceTimeHighResolution is always seen to be false at that stage and hence the timer period is never set to 1ms. Because the flag also disables per-sleep changes to the timer, the net result is that use of this flag actually disables all use of the high-resolution timer for sleep purposes.

You can use perfmon, on Windows, to display the interrupts/sec that the system is experiencing. Select a scale factor of 1 and set the Y  customer  to cover 0-1000. Under a normal 10ms timer period you will see around 100+ interrupts/sec. With the 1ms timer period you will see this shoot up to 1000+ interrupts/sec.

NOTE: Changing the timer period is a system wide action and so Windows operates the timer at the shortest period requested by any running application. On some systems you will find that some other piece of software has already set a 1ms period and so the operation of the VM, with or without ForceTimeHighresolution, has no effect on the timer period.

Edited to stop the censoring software from changing " customer " to "customer"
Posted Date : 2009-01-05 04:06:04.0

Do not use ForceTimeHighResolution but instead, at the start of the application create and start a daemon Thread that simply sleeps for a very long time (that isn't a multiple of 10ms) as this will set the timer period to be 1ms for the duration of that sleep - which in this case is the lifetime of the VM:

       new Thread() {
            { this.setDaemon(true); this.start(); }
            public void run() {
                    while(true) {
                        try {
                            Thread.sleep(Integer.MAX_VALUE);
                        }
                        catch(InterruptedException ex) {
                        }
                    }
            }
        };

Note that as the sleep never terminates the timer period is never restored by the VM. This is not a problem however because it seems windows tracks the changes to the timer in the process control block and removes the change when the process terminates. This particular feature of these API's is not documented however, but the use of the PCB is mentioned in one of the "inside NT" articles, because it stops a process from calling timeEndPeriod if it never called timeBeginPeriod. It does make sense that the OS would not simply trust the application to do the right thing here.

Fixing this bug is on the one hand trivial, and on the other very tricky. The code change is trivial. The problem is that this switch has been failing to operate as intended for several years now, yet there have been no reports of this issue from anyone using the switch, so anyone using the switch must be satisfied with the way their application is behaving and so fixing this bug could adversely affect those applications.

It may be that we have to leave this switch as broken. A position that is more acceptable when one considers the simple workaround available.
Posted Date : 2006-06-07 06:41:53.0

----------------------------------------

Re-targetting for Dolphin (Java 7) as part of the 5005837 work.
Posted Date : 2006-06-28 21:52:21.0

The workaround outlined above is not really working. I still have problems when it comes to wait 8ms. That causes my Sprite to move unsmooth. It is very annoying, because I cannot do anything! Maybe there is an additional error in Time measurement too. 
Stefan.Kolb@o2online.de

The workaround should cause the timer interrupt to be set to 1ms - you should be able to verify this using the perfmon tool. Please advise if this is not the case, with full platform details and VM version.

For the more general issue of using clocks and timers on win32 please see my blog entry:
http://blogs.sun.com/dholmes/entry/inside_the_hotspot_vm_clocks

Ran across this on windows 2000.  The workaround seems to be working.  Windows 2003 doesn't seem to exploit this bug, so I'd say MS has changed something..

I am confirming the bug on JDK 6 Update 6 running on Windows 2003 SP2.

(that is "system time goes too fast when calling sleep(45)")

David Balažic <xerces(5+3) aat butn period net>
(yes, that is an eight)

The bug is still in Windows 2008 SP1 (and presumably Vista SP1, since they are the same).
Tried single CPU/core system and a quad core system.

David

I'm unclear what is being reported as still being in Windows 2008. This bug (the fact that the flag works incorrectly) has not been fixed in the JDK - period.

Whether later Windows versions have changed the default timer interrupt rate I can't say. But note that some applications you run - particular multi-media apps will change the timer rate. So it is entirely possible that on a "multi-media" version of Windows that a higher timer rate is always in effect. Again the perfmon tool can be used to show this.

Sorry, I was referring to the "system time goes too fast when calling sleep(45)"  issue of Windows.
David

How do we fix this problem for our JBoss-Application-Server? You should not start threads in an app server.
And the other problem is were should we place this Daemon-Thread?

Should we start a "TimeAdjustApp" that only contains this daemon thread?

The daemon thread just has to exist in a VM on the system - it only takes the presence of one application to change the interrupt rate. I don't know how JBOss is deployed, nor how apps are run on it so I can't be more specific.