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