JDK-4500875 : Very few CPU sampling due to failure in wait_for_suspend_completion
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.4.0
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2001-09-07
  • Updated: 2001-12-03
  • Resolved: 2001-12-03
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.0 beta3Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Description
JDK1.4 hprof takes very few CPU sampling.

Using Merlin build 78, hprof takes only about 39 CPU sampling on my sample
test case (see below).

Using Ladybird build 24, hprof takes about 750 CPU sampling instead.

Sample test case:
import java.io.*;

public class CPUSampling {
  public static void main(String[] args) {
    long t0 = System.currentTimeMillis();
    int n = 0;
    for (int i = 0; i < 0x7FFFFFF0; i++) {
      n += i;
    }
    long t1 = System.currentTimeMillis();
    System.out.println("Real time: " + (t1 - t0));
  }
}

I have seen this problem on Solaris Sparc but we shall also try on other
platform to see if it's a problem.

Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: merlin-beta3 FIXED IN: merlin-beta3 INTEGRATED IN: merlin-beta3 VERIFIED IN: merlin-rc1
14-06-2004

EVALUATION ###@###.### 2001-09-12 This problem occurs on Solaris and Linux. I believe it also occurs on Win32 but haven't verified that. This is a problem in wait_for_suspend_completion to determine if a thread is completely suspended. When a thread is _thread_blocked state but is blocking in OS system call, (so its osthread state is RUNNABLE), wait_for_suspend_completion considers such thread not suspended. The main reason why it didn't show up in Ladybird because Signal thread is blocking on a monitor instead of a semaphore and wait_for_suspend_completion handles CONDVAR_WAIT case and count it as good as suspended. The problem exists in Ladybird as well if a thread is blocking on a OS system call. ###@###.### 2001-11-07 The fix for this bug has caused regressions (see 4510838). A new bug 4524391 has filed to implement a revised fix for this bug to workaround 4510838. ###@###.### 2001-12-03 Executed the given test case and here are my observations with different builds Merlin b88 : % grep "CPU SAMPLES" mb88 CPU SAMPLES is a statistical profile of program execution. The VM HEAP DUMP, SITES, CPU SAMPLES|TIME and MONITOR DUMP|TIME records are generated CPU SAMPLES BEGIN (total = 666) Mon Dec 3 13:00:26 2001 CPU SAMPLES END Merlin b78 : % grep "CPU SAMPLES" mb78 CPU SAMPLES is a statistical profile of program execution. The VM HEAP DUMP, SITES, CPU SAMPLES|TIME and MONITOR DUMP|TIME records are generated CPU SAMPLES BEGIN (total = 23) Mon Dec 3 13:03:38 2001 CPU SAMPLES END Ladybird b23 : % grep "CPU SAMPLES" lb23 CPU SAMPLES is a statistical profile of program execution. The VM HEAP DUMP, SITES, CPU SAMPLES|TIME and MONITOR DUMP|TIME records are generated CPU SAMPLES BEGIN (total = 432) Mon Dec 3 13:01:56 2001 CPU SAMPLES END Closing this bug as fixed and verified
11-06-2004

SUGGESTED FIX ###@###.### 2001-09-24 Count threads that are in _thread_blocked state "as good as suspended". 2737,2739c2737,2741 < if (thd->osthread()->get_state() == CONDVAR_WAIT) { < // If we have reached CONDVAR_WAIT state, i.e., wait for Java < // ObjectMonitor, then that is the same as externally suspended --- > if (thd->osthread()->get_state() == CONDVAR_WAIT || > thd->thread_state() == _thread_blocked) { > // If we have reached CONDVAR_WAIT state or in _thread_blocked state, > // i.e., wait for Java ObjectMonitor or OS system call, > // then that is the same as externally suspended
11-06-2004

PUBLIC COMMENTS .
10-06-2004