JDK-4712392 : REGRESSION: Reduced default resolution for Thread.sleep() breaks apps.
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.4.1
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_98,windows_2000
  • CPU: x86
  • Submitted: 2002-07-09
  • Updated: 2012-10-08
  • Resolved: 2006-05-08
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.1 1.4.1Fixed
Related Reports
Relates :  
JDK-4653558 - Java Application startup time is SLOW in JDK 1.4 compared to JDK 1.3.1_02
Relates :  
JDK-4717583 - High resolution Thread.sleep() needs lower overhead on Windohs
Relates :  
JDK-4500388 - Calling Thread.sleep with small argument affects system clock on windows
Relates :  
JDK-5005837 - rework win32 timebeginperiod usage
Description
JDK1.4.1 has introdued a reduced resolution under the Windows paltform of Thread.sleep().  This reduction in resolution makes high resolution time-keeping with sleep() break.  (Time keeping with sleep() is a workaround commonly in use for the afct that we never supported a decent resolution in currentTimeMillis() on Win32 platforms.)

 ========

This is also a problem for Java Media Framework on Windows, since they were
depending on winmm being loaded and having high res sleep in order to display
video smoothly.
###@###.### 2002-07-10

======================

Please look at comments as well.
###@###.### 2002-07-12
Comments
EVALUATION This specific regression was fixed in 1.4.1 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.
08-05-2006
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper-rc FIXED IN: hopper-rc INTEGRATED IN: hopper-rc
14-06-2004
SUGGESTED FIX One of three solutions: (1) As this fix only helped a small number fo machiens i na non-critical maner, back the fix out. (2) As this fix helped only a small number of machines in a non critical manner, reverse the default setting of the command line flag controlling this feature such that default is to operate as it always has. (3) Monitor the requested sleep duration and, if a duration is requested that is not evenly divisible by the lower resolution provided, automaticly default to the older higher resolution code.
11-06-2004
EVALUATION The decision is to back out the changes for 4653558 and change the default value of ForceHighResolutionTime from false to true. With those changes, sleeps of less than the platform default will be more accurate, at the expense of the startup cost of loading winmm.dll, and the runtime cost of the machine fielding more clock interrupts during a high-resolution sleep. ###@###.### 2002-07-10 We decided that the only safe thing to do at this point in the release is to back out the changes for 4653558 completely, not trying to do anything fancy with ForceHighResolutionTime (which, because we are backing out the changes, goes back to being named ForceTimeHighResolution). ###@###.### 2002-07-16 Removed mantis from integrated in release per p-team ###@###.### 2002-10-18
16-07-2002