JDK-6435126 : ForceTimeHighResolution switch doesn't operate as intended
  • Type: Bug
  • Status: Closed
  • Resolution: Won't Fix
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Affected Version: 5.0u6,6
  • OS: windows,windows_xp
  • CPU: generic,x86
  • Submit Date: 2006-06-07
  • Updated Date: 2012-07-23
  • Resolved Date: 2012-07-23
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
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 axis 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 "axis" to "customer"

EVALUATION This has been broken for too long. No use fixing it now.

SUGGESTED FIX ------------------- Or better, defer changing the timer period until a sleep is actually requested.

EVALUATION ---------------------------------------- Re-targetting for Dolphin (Java 7) as part of the 5005837 work.

EVALUATION 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.

WORK AROUND 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.

SUGGESTED FIX Move the setting of the 1ms timer period out of DllMain and into the init_2() method (called after command-line arguments have been processed).