JDK-2151447 : Bigapps Failure- the app is hanging with the specific VM
  • Type: Backport
  • Backport of: JDK-6571496
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2007-08-01
  • Updated: 2011-03-08
  • Resolved: 2011-03-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.
JDK 6 Other
6u4Fixed hs11Fixed
Comments
EVALUATION At one stage we create a new placeholder entry and then do a final check in case the target class was loaded in parallel. If it was we simply return that. But we don't remove the new placeholder, or rat her we don't call remove_seen_thread on the placeholder entry. This causes a problem for threads that have entered the wait() loop. Here's an attempted description of the failure scenario: - thread A is doing the actual load and has created a placeholder entry - thread B sees the placeholder and starts doing the wait() - thread C sees the placeholder and blocks on the SD lock prior to the code that will do the wait() - thread A completes the load, removes the placeholder and does a notifyAll - thread B returns from wait(), escapes the wait-loop because there's no placeholder with a load-in- progress, creates a new placeholder entry, then finds that A already loaded the class and so returns it - thread C gets the SD lock, sees the placeholder created by B and so does a wait() for which there is no direct notify. Even if an unrelated notify occurs, thread C continues to see B's placeholder an d so keeps on looping and wait()ing forever.
01-08-2007