JDK-6593550 : D3D: SwingSet2 freeze when moving from one monitor to the other, WinXP
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 6u5
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2007-08-16
  • Updated: 2010-10-14
  • Resolved: 2007-09-05
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 b03Fixed
Related Reports
Relates :  
JDK-6596702 - D3D: intermittent repainting issues in SwingSet after restoring from fs mode
Description
I am launching SwingSet2 using 6u4-b01 on WinXP-ATI Radeon 9600 installed with the latest driver (7.8). This is a multimonitor machine. When SwingSet2 is loading, I am moving it from the primary to secondary screen. The Window stops in-between the 2 screens and it is frozen. I had to kill it using Task Manager. 

This is reproducible only on 6u4-b01 and not in 6u3 and hence this is a regression due to D3D changes. I have made sure D3D is enabled on the system by setting J2D_TRACE_LEVEL to 4. 

Here is the thread dump at the time of freeze:
-----------------------------------------------
Full thread dump Java HotSpot(TM) Client VM (1.6.0_04-ea-b01 mixed mode, sharing
):

"D3D Screen Updater" daemon prio=8 tid=0x00a08800 nid=0x1e64 in Object.wait() [0
x00b0f000..0x00b0fa94]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22f913a0> (a java.lang.Object)
        at sun.java2d.d3d.D3DScreenUpdateManager.run(D3DScreenUpdateManager.java
:327)
        - locked <0x22f913a0> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:619)

"DestroyJavaVM" prio=6 tid=0x009c0c00 nid=0x1fa0 waiting on condition [0x0000000
0..0x00d1fd4c]
   java.lang.Thread.State: RUNNABLE

"TimerQueue" daemon prio=6 tid=0x03364800 nid=0x1df0 in Object.wait() [0x0356f00
0..0x0356fd94]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22f2d2c8> (a javax.swing.TimerQueue)
        at javax.swing.TimerQueue.run(TimerQueue.java:236)
        - locked <0x22f2d2c8> (a javax.swing.TimerQueue)
        at java.lang.Thread.run(Thread.java:619)

"AWT-EventQueue-0" prio=6 tid=0x0334a800 nid=0x16c runnable [0x032ef000..0x032ef
a14]
   java.lang.Thread.State: RUNNABLE
        at sun.java2d.d3d.D3DRenderQueue.flushBuffer(Native Method)
        at sun.java2d.d3d.D3DRenderQueue.flushBuffer(D3DRenderQueue.java:118)
        at sun.java2d.d3d.D3DRenderQueue.flushAndInvokeNow(D3DRenderQueue.java:1
08)
        at sun.java2d.d3d.D3DSurfaceData.initSurface(D3DSurfaceData.java:373)
        at sun.java2d.d3d.D3DSurfaceData.<init>(D3DSurfaceData.java:235)
        at sun.java2d.d3d.D3DSurfaceData.createData(D3DSurfaceData.java:256)
        at sun.java2d.d3d.D3DVolatileSurfaceManager.initAcceleratedSurface(D3DVo
latileSurfaceManager.java:75)
        at sun.awt.image.VolatileSurfaceManager.initialize(VolatileSurfaceManage
r.java:97)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:66)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:76)
        at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:87)
        at sun.java2d.d3d.D3DGraphicsConfig.createBackBuffer(D3DGraphicsConfig.j
ava:140)
        at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java
:397)
        - locked <0x22fb52f8> (a sun.awt.windows.WFramePeer)
        - locked <0x22eac7b8> (a java.awt.Component$AWTTreeLock)
        at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java
:365)
        at sun.awt.windows.WComponentPeer.displayChanged(WComponentPeer.java:450
)
        at sun.awt.windows.WCanvasPeer.displayChanged(WCanvasPeer.java:39)
        at sun.awt.windows.WPanelPeer.displayChanged(WPanelPeer.java:134)
        at sun.awt.windows.WWindowPeer.displayChanged(WWindowPeer.java:407)
        at sun.awt.windows.WWindowPeer$1.run(WWindowPeer.java:350)
        at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
        at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
        at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThre
ad.java:273)
        at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.
java:183)
        at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThre
ad.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)

"AWT-Windows" daemon prio=6 tid=0x00a8c000 nid=0x1eb4 waiting for monitor entry
[0x0323e000..0x0323fa94]
   java.lang.Thread.State: BLOCKED (on object monitor)
        at sun.awt.windows.WComponentPeer.destroyBuffers(WComponentPeer.java:815
)
        - waiting to lock <0x22fb52f8> (a sun.awt.windows.WFramePeer)
        at java.awt.Component$FlipBufferStrategy.destroyBuffers(Component.java:3
700)
        at java.awt.Component$FlipBufferStrategy.createBuffers(Component.java:36
24)
        at java.awt.Component$FlipBufferStrategy.revalidate(Component.java:3760)

        at java.awt.Component$FlipSubRegionBufferStrategy.validateAndShow(Compon
ent.java:4100)
        at javax.swing.BufferStrategyPaintManager.show(BufferStrategyPaintManage
r.java:249)
        at javax.swing.RepaintManager.show(RepaintManager.java:1208)
        at javax.swing.SwingPaintEventDispatcher.createPaintEvent(SwingPaintEven
tDispatcher.java:43)
        at sun.awt.windows.WComponentPeer.postPaintIfNecessary(WComponentPeer.ja
va:697)
        at sun.awt.windows.WComponentPeer.handleExpose(WComponentPeer.java:681)
        at sun.awt.windows.WToolkit.eventLoop(Native Method)
        at sun.awt.windows.WToolkit.run(WToolkit.java:291)
        at java.lang.Thread.run(Thread.java:619)

"AWT-Shutdown" prio=6 tid=0x00a8b000 nid=0x1bb4 in Object.wait() [0x031ef000..0x
031efb14]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22ea69f8> (a java.lang.Object)
        at java.lang.Object.wait(Object.java:485)
        at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
        - locked <0x22ea69f8> (a java.lang.Object)
        at java.lang.Thread.run(Thread.java:619)

"Java2D Disposer" daemon prio=10 tid=0x00a8a400 nid=0x1b6c in Object.wait() [0x0
319f000..0x0319fb94]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22ea6a88> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x22ea6a88> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at sun.java2d.Disposer.run(Disposer.java:125)
        at java.lang.Thread.run(Thread.java:619)

"Low Memory Detector" daemon prio=6 tid=0x009f6400 nid=0x14dc runnable [0x000000
00..0x00000000]
   java.lang.Thread.State: RUNNABLE

"CompilerThread0" daemon prio=10 tid=0x009e8800 nid=0x1a6c waiting on condition
[0x00000000..0x0309f640]
   java.lang.Thread.State: RUNNABLE

"Attach Listener" daemon prio=10 tid=0x009e7400 nid=0x1aa0 runnable [0x00000000.
.0x00000000]
   java.lang.Thread.State: RUNNABLE

"Signal Dispatcher" daemon prio=10 tid=0x009e6800 nid=0x187c waiting on conditio
n [0x00000000..0x00000000]
   java.lang.Thread.State: RUNNABLE

"Finalizer" daemon prio=8 tid=0x009e1c00 nid=0x1ad0 in Object.wait() [0x02faf000
..0x02fafa94]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22ea6cb8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116)
        - locked <0x22ea6cb8> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)

"Reference Handler" daemon prio=10 tid=0x009dd800 nid=0x18a8 in Object.wait() [0
x02f5f000..0x02f5fb14]
   java.lang.Thread.State: WAITING (on object monitor)
        at java.lang.Object.wait(Native Method)
        - waiting on <0x22ea6d40> (a java.lang.ref.Reference$Lock)
        at java.lang.Object.wait(Object.java:485)
        at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
        - locked <0x22ea6d40> (a java.lang.ref.Reference$Lock)

"VM Thread" prio=10 tid=0x009d4400 nid=0xfd4 runnable

"VM Periodic Task Thread" prio=10 tid=0x009f7800 nid=0x1950 waiting on condition


JNI global references: 1158

Heap
 def new generation   total 2112K, used 1551K [0x22990000, 0x22bd0000, 0x22e7000
0)
  eden space 1920K,  79% used [0x22990000, 0x22b0ddc8, 0x22b70000)
  from space 192K,  12% used [0x22b70000, 0x22b75e70, 0x22ba0000)
  to   space 192K,   0% used [0x22ba0000, 0x22ba0000, 0x22bd0000)
 tenured generation   total 26904K, used 23111K [0x22e70000, 0x248b6000, 0x26990
000)
   the space 26904K,  85% used [0x22e70000, 0x24501f60, 0x24502000, 0x248b6000)
 compacting perm gen  total 12288K, used 2081K [0x26990000, 0x27590000, 0x2a9900
00)
   the space 12288K,  16% used [0x26990000, 0x26b986c8, 0x26b98800, 0x27590000)
    ro space 8192K,  66% used [0x2a990000, 0x2aed98f0, 0x2aed9a00, 0x2b190000)
    rw space 12288K,  52% used [0x2b190000, 0x2b7d31a0, 0x2b7d3200, 0x2bd90000)
I have noticed few other issues -

1. When SwingSet2 is visible on the screen, I am pushing the command prompt to FS mode and restoring to enforce a surface loss. Doing this a few times makes some of the components appear black.

2. Push the command prompt to FS mode and restore it. After that, move the SwingSet2 from one screen to the other. The entire UI becomes garbled.

These issues are not seen on 6u3.
This is reproducible with most of the volatile applications. I have attached herewith a volatile image application. Just run the application on a multi-mon setup and try to move it a bit. You will notice that the application freeze.
I have seen a similar hang on single-mon-Vista when I ran a volatile image test and enabled the GoldFish Aquarium screensaver from LifeGlobe. When the app is running, I enable the screensaver and restore it. The VolatileImage shows 'Image_Incompatible' status and not restored. Intermittently the app freezes with a similar stack trace. Looks like the screen-saver is running in 16 bit mode and hence there is a display mode change. I have attached the app herewith.
Comments
SUGGESTED FIX http://sa.sfbay.sun.com/projects/java2d_data/6u5/6593550.0
27-08-2007
EVALUATION Filed a new bug to track the restoration issues: 6596702: D3D: intermittent repainting issues in SwingSet after restoring from fs mode
24-08-2007
EVALUATION Note that the surface restoration issue after alt+tabbing from a fs application mentioned in the description is a different problem and should be filed as a separate bug.
23-08-2007
EVALUATION I believe I have found a solution to this particular problem. Currently the BufferStrategyRepaintManager validates the strategy before showing it (while on the toolkit thread), which is the reason for the deadlock as many of the operations during the validation take various locks including the WComponentPeer lock - a big no-no on the toolkit thread. I don't see why validating on the toolkit thrad is necessary - we could only flip the strategy if it is not lost. If it is lost, then it could just do what it currently does if the strategy got lost _after_ the show() - basically issue a repaint event. This will "move" the restoration of the strategy on the EDT during the handling of the paint event as it is done now anyway. So the simple fix is not to call 'validate(false)' from validateAndShow(), but only show() the strategy if it is not restored or lost. (I guess validateAndShow() would need to be renamed to something like showIfValid()). This fix will also eliminate the need for a couple of hacks that were put in to allow executing calls requiring the RenderQueue lock on the toolkit thread. All those calls were made during the validation/restoration of the buffer strategy on the toolkit thread. We could get rid of the hack in D3DRenderer.fillRect() and D3DSurfaceData.initSurface(). We'd still need it in D3DSurfaceData.swapBuffers() since that call will need to be called on the toolkit thread.
23-08-2007
EVALUATION Looks like there are two separate issues here. First, there's a deadlock that sometimes happens when moving from one screen to another between the Toolkit thread EDT: "AWT-Windows" daemon prio=6 tid=0x00a9d800 nid=0x133c waiting for monitor entry [0x0b48e000..0x0b48fc94] java.lang.Thread.State: BLOCKED (on object monitor) at sun.awt.windows.WComponentPeer.destroyBuffers(WComponentPeer.java:815) - waiting to lock <0x03370930> (a sun.awt.windows.WFramePeer) at java.awt.Component$FlipBufferStrategy.destroyBuffers(Component.java:3700) at java.awt.Component$FlipBufferStrategy.createBuffers(Component.java:3624) at java.awt.Component$FlipBufferStrategy.revalidate(Component.java:3760) at java.awt.Component$FlipSubRegionBufferStrategy.validateAndShow(Component.java:4100) at javax.swing.BufferStrategyPaintManager.show(BufferStrategyPaintManager.java:249) at javax.swing.RepaintManager.show(RepaintManager.java:1208) at javax.swing.SwingPaintEventDispatcher.createPaintEvent(SwingPaintEventDispatcher.java:43) at sun.awt.windows.WComponentPeer.postPaintIfNecessary(WComponentPeer.java:697) at sun.awt.windows.WComponentPeer.handleExpose(WComponentPeer.java:681) at sun.awt.windows.WToolkit.eventLoop(Native Method) at sun.awt.windows.WToolkit.run(WToolkit.java:291) at java.lang.Thread.run(Thread.java:619) "AWT-EventQueue-0" prio=6 tid=0x0b22b800 nid=0x1538 runnable [0x0b52f000..0x0b52fc14] java.lang.Thread.State: RUNNABLE at sun.java2d.d3d.D3DRenderQueue.flushBuffer(Native Method) at sun.java2d.d3d.D3DRenderQueue.flushBuffer(D3DRenderQueue.java:118) at sun.java2d.d3d.D3DRenderQueue.flushAndInvokeNow(D3DRenderQueue.java:108) at sun.java2d.d3d.D3DSurfaceData.initSurface(D3DSurfaceData.java:373) at sun.java2d.d3d.D3DSurfaceData.<init>(D3DSurfaceData.java:235) at sun.java2d.d3d.D3DSurfaceData.createData(D3DSurfaceData.java:256) at sun.java2d.d3d.D3DVolatileSurfaceManager.initAcceleratedSurface(D3DVolatileSurfaceManager.java:75) at sun.awt.image.VolatileSurfaceManager.initialize(VolatileSurfaceManager.java:97) at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:66) at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:76) at sun.awt.image.SunVolatileImage.<init>(SunVolatileImage.java:87) at sun.java2d.d3d.D3DGraphicsConfig.createBackBuffer(D3DGraphicsConfig.java:140) at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:397) - locked <0x03370930> (a sun.awt.windows.WFramePeer) - locked <0x0325e108> (a java.awt.Component$AWTTreeLock) at sun.awt.windows.WComponentPeer.replaceSurfaceData(WComponentPeer.java:365) at sun.awt.windows.WComponentPeer.displayChanged(WComponentPeer.java:450) at sun.awt.windows.WCanvasPeer.displayChanged(WCanvasPeer.java:39) at sun.awt.windows.WPanelPeer.displayChanged(WPanelPeer.java:134) at sun.awt.windows.WWindowPeer.displayChanged(WWindowPeer.java:407) at sun.awt.windows.WWindowPeer$1.run(WWindowPeer.java:350) 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) This is an age old issue of too much sync-ing in replaceSurfaceData, but it happens more readily now because we have other threads depending on the Toolkit thread. I have also been able to reproduce the repainting issues with fullscreen change. That will also need to be investigated, but it is unlikely that these two are related, so I will probably file a separate bug for this.
16-08-2007