JDK-6647449 : D3D: D3DScreenUpdateManager.validate() may cause taking RQ lock on RQ thread
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u10
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2008-01-05
  • Updated: 2019-12-17
  • Resolved: 2019-12-17
Description
While testing another fix which changed the display mode a lot 
I have bumped into the following deadlock (in another application which
was running at the time):
Stack trace: 
sun.misc.Unsafe.park(Native Method)
java.util.concurrent.locks.LockSupport.park(Unknown Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(Unknown Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(Unknown Source)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(Unknown Source)
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(Unknown Source)
java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
sun.awt.SunToolkit.awtLock(Unknown Source)
sun.java2d.pipe.RenderQueue.lock(Unknown Source)
sun.java2d.d3d.D3DSurfaceData.initSurface(Unknown Source)
sun.java2d.d3d.D3DSurfaceData.restoreSurface(Unknown Source)
sun.java2d.d3d.D3DSurfaceData$D3DWindowSurfaceData.restoreSurface(Unknown Source)
sun.java2d.d3d.D3DScreenUpdateManager.validate(Unknown Source)
sun.java2d.d3d.D3DScreenUpdateManager.createGraphics(Unknown Source)
   - locked sun.java2d.d3d.D3DScreenUpdateManager@1dd1a31
sun.awt.windows.WComponentPeer.getGraphics(Unknown Source)
java.awt.Component.getGraphics_NoClientCode(Unknown Source)
java.awt.Component$BltBufferStrategy.showSubRegion(Unknown Source)
java.awt.Component$BltSubRegionBufferStrategy.showIfNotLost(Unknown Source)
javax.swing.BufferStrategyPaintManager.show(Unknown Source)
javax.swing.RepaintManager.show(Unknown Source)
javax.swing.SwingPaintEventDispatcher.createPaintEvent(Unknown Source)
sun.awt.windows.WComponentPeer.postPaintIfNecessary(Unknown Source)
sun.awt.windows.WComponentPeer.handleExpose(Unknown Source)
sun.awt.windows.WToolkit.eventLoop(Native Method)
sun.awt.windows.WToolkit.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

Another thread in the deadlock was the EDT.
Comments
EVALUATION There's a hard requirement: the render queue lock must not be taken on the render queue thread. In this case attempt to restore the on-screen surface on the toolkit thread (which is the renderng thread). It is yet unclear how did we manage to end up with Blit buffer strategy there - this will need further investigation. It seems likely that it happened because of repeated display mode changes, so at some point swing requested a new BS while the device was lost, and we ended up returning false from Win32GraphicsEnvironment.isFlipStrategyPreferred(). Which means that we might end up performing d3d Blits from the RQ thread as well. So we might need to disable buffer per window repainting somehow for this case (d3d enabled but no flip strategy). One possible workaround for the surface restoration attempt would be to check if we're on the rendering queue in validate() and return false if that's the case. But that will not be sufficient since we could still end up doing d3d blits (and taking the rq lock) on the RQ.
05-01-2008