JDK-4143186 : Native threads VM running the rmiregistry uses 100% CPU
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 1.1.6,1.2.0
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS:
    solaris_2.5,solaris_2.5.1,solaris_2.6 solaris_2.5,solaris_2.5.1,solaris_2.6
  • CPU: sparc
  • Submitted: 1998-05-27
  • Updated: 1999-01-15
  • Resolved: 1999-01-15
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.2.0 1.2beta4Fixed
Related Reports
Duplicate :  
JDK-4239970 - IllegalMonitorStateException in Thread.sleep during Y2K testing
Duplicate :  
JDK-4142926 - Object.wait(long) throws IllegalMonitorStateException for large numbers
Relates :  
JDK-4013568 - Although Java API's specify sleep and wait values as 64-bit, we only use 32 bits
Description

Name: moC74494			Date: 05/27/98


We have found a problem with rmiregistry under native threads on 
Solaris, JDK version JDK1.2beta4_G.
The VM running the rmiregistry consumes 100% CPU and seems to be 
unresponsive to clients. This behavior does not reproduce with 
green threads.

Here is a diagnosis and (possible) fix:
In sun/rmi/registry/RegistryImpl.java near line 264, 
Thread.sleep() is called with the argument Long.MAX_VALUE.

Under the native thread implementation, the current time in millis is
added to the argument before calling cond_wait.

  From condvar_md.c:
(dbx) list condvarTimedWait
  122   {
  123       sigjmp_buf jmpbuf;
  124       int err;
  125       timestruc_t timeout;
  126       sys_thread_t *self;
  127       int64_t end_time = sysTimeMillis() + millis;
  128   

The resulting value overflows and an invalid timestruc_t is
constructed and passed in into cond_timedwait(), which returns
with an error code of 22 (EINVAL). This is masked and silently
ignored by upper layers of the system and no exception is reported
to the user.

Thus, instead of sleeping for ever, the thread ends up running hot.
(Review ID: 32479)
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: generic FIXED IN: 1.2beta4 INTEGRATED IN: 1.2beta4
14-06-2004
WORK AROUND Name: moC74494 Date: 05/27/98 Changing the argument from Long.MAX_VALUE to Integer.MAX_VALUE fixes this problem. You may also want to consider reporting the system error to the user if an invalid argument is supplied to Thread.sleep(). ======================================================================
11-06-2004
EVALUATION The bug is that sysMonitorWait on native threads doesn't deal with really large sleep times properly. Thread.sleep is actually implementated in terms of sysMonitorWait, as is Object.wait(int). You can see the problem more acutely with Object.wait(int) since this will incorrectly report an IllegalMonitorStateException when this happens. The fix is to treat values larger than Integer.MAX_VALUE as infinity, which is how green threads and win32 handle this. This isn't strictly correctly since we probably should be able to wait for a much longer period than this and the interface implies that we have the whole range on a signed 64-bit number available. This problem is covered by another bug, 4013568. tom.rodriguez@Eng 1998-06-01
01-06-1998