JDK-6626580 : D3D: WComponentPeer.destroyBuffers should not be synchronized
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-11-06
  • Updated: 2010-10-15
  • Resolved: 2007-11-20
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
6u10 b08Fixed
Description
I've ran into the following deadlock when switching from
full-screen to windowed mode in Firestarter:
Found one Java-level deadlock:
=============================
"Thread-4":
  waiting to lock monitor 0x0c5dd26c (object 0x04a31cd8, a java.awt.Component$AWTTreeLock),
  which is held by "AWT-EventQueue-0"
"AWT-EventQueue-0":
  waiting to lock monitor 0x0c5dd204 (object 0x04a2c990, a sun.awt.windows.WFramePeer),
  which is held by "Thread-4"

Java stack information for the threads listed above:
===================================================
"Thread-4":
        at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:382)
        - waiting to lock <0x04a31cd8> (a java.awt.Component$AWTTreeLock)
        at sun.awt.windows.WComponentPeer.destroyBuffers(WComponentPeer.java:829)
        - locked <0x04a2c990> (a sun.awt.windows.WFramePeer)
        at java.awt.Component$FlipBufferStrategy.destroyBuffers(Component.java:3700)
        at java.awt.Component$FlipBufferStrategy.dispose(Component.java:3818)
        at java.awt.Component.createBufferStrategy(Component.java:3447)
        at java.awt.Window.createBufferStrategy(Window.java:2968)
        at java.awt.Component.createBufferStrategy(Component.java:3383)
        at java.awt.Window.createBufferStrategy(Window.java:2943)
        at GameFrame.show(Unknown Source)
        at ParticleAnim.run(Unknown Source)
        at java.lang.Thread.run(Thread.java:619)
"AWT-EventQueue-0":
        at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:383)
        - waiting to lock <0x04a2c990> (a sun.awt.windows.WFramePeer)
        - locked <0x04a31cd8> (a java.awt.Component$AWTTreeLock)
        at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:367)
        at sun.awt.windows.WComponentPeer$2.run(WComponentPeer.java:430)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
        at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
        at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)

Found 1 deadlock.

Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u10/6626580.0
07-11-2007

EVALUATION The cause of the deadlock is that WComponentPeer.destroyBuffers() is synchronized, which causes it to take the locks in a reversed order from all other places: it first takes peer lock, then AWTTree lock. In fact destroyBuffers() shouldn't be synchronized at all since replaceSurfaceData() already takes care of synchronization.
06-11-2007