JDK-4379031 : java -Xrunhprof:cpu=samples PepTest intermittently hangs
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmpi
  • Affected Version: 1.3.1
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_7
  • CPU: sparc
  • Submitted: 2000-10-13
  • Updated: 2002-09-06
  • Resolved: 2002-09-06
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.3.1 rc1Fixed
Related Reports
Relates :  
Description
With the current implementation of jvmpi suspend/resume, running
java -Xrunhprof:cpu=samples in a forever loop will hang after
about a dozen runs on Solaris.

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

EVALUATION 1) With the current JVMPI suspend/resume mechanism, you get intermittent hangs. 2) Modifying the JVMPI suspend/resume mechanism to use the same mechanism that jvm uses you still get intermittent hangs until you fix the timing problems with the existing external suspend/resume mechanism Timing holes were: Timing Hole 1: Thread 1 requests a suspend of Thread 2, but has not yet set is_java_suspended or pending_java_suspend, but the request has returned. Thread 1 requests a resume of Thread 2, java_resume checks if (is_java_suspended == FALSE) and returns doing nothing. Thread 1 then can continue with suspension and the resume was lost. Fix 1: Use JVMDI mechanism to not return to the caller until pending_java_suspend is set. Use this for jvmpi, jvm and shared copy for jvmdi. Timing Hole 2: Thread 1 requests a suspend for Thread 2 and sets pending_java_suspend. In Thread 2, Handle_special_runtime_exit_condition checks for pending_java_suspend and then clears pending_java_suspend. Thread 1 requests a resume for Thread 2, java_resume checks for is_being_java_suspended and returns doing nothing. Thread 2 then continues with suspension, losing the resume. Fix 2: Always set pending_java_suspend when starting any suspension. Check and clear pending_java_suspend INSIDE Interrupt_Lock (for Solaris/Win32, Threads Lock for Linux) In suspend: clear pending_java_suspend AFTER setting is_java_suspended In resume: move check for is_java_suspended inside Interrupt_Lock Timing Hole 3: On solaris, you can get is_java_suspended without osstate set to SUSPENDED Fix 3: To handle that case, you need to have the resume code retry. The implementation chosen was to release the Interrupt_Lock, return to the caller and let them retry.
11-06-2004