SYNOPSIS
--------
Regression : Deadlock between AWT-XAWT thread and AWT-EventQueue-0 Thread when screen resolution changes

OPERATING SYSTEM
----------------
Linux

FULL JDK VERSION
----------------
Java 8 b17 onwards

PROBLEM DESCRIPTION from LICENSEE
---------------------------------
The RFE for 7045370 means that Java 8 can detect screen resolution changes and update its display with new resolution (screen width and height).

While testing this feature, we observe that occasionally a Java application GUI with the focus becomes non-responsive soon after a screen resolution change. The deadlock occurs between the AWT-XAWT event dispatch thread and the AWT-EventQueue-0 event dispatch thread. Another customer has reported a deadlock between same threads but a slightly different scenario (CR 7105941) - it seems unlikely, but this issue may or may not be related.

When a screen resolution change occurs, X11 seems to dispatch 2 XConfigureNotify events. The first one is for the current resolution, and the second for the new resolution. We have analysed this in detail, and we found that the problem seems to occur when there is a delay with the second XConfigureNotify event, with other X11 events (XVisibilityNotify and XExpose) occurring in between.

The result of that scenario is that the AWT-EventQueue-0 thread will issue a repaint event and in order to do that it grabs the AWTTreeLock. Meanwhile, the second XConfigureNotify event dispatch occurs and the AWT-XAWT thread grabs the toolkit AWT lock (ReentrantLock). AWT-XAWT then requires the the AWTTreeLock to grab the current window's GraphicsConfiguration, while AWT-EventQueue-0 requires the toolkit AWT lock to render the repainted image into the X11 surface. The result is a classic deadlock.

In the passing case, two XConfigureNotify events occur in a close timing window with no XVisibilityNotify and XExpose in between. No repaint is triggered between the two events and no deadlock occurs.

As AWT-EventQueue-0 and AWT-XAWT shares locks there is always a chance to get into a deadlock scenario if a particular lock sequence is breached. As explained there are different scenario for these thread to get into a deadlock state (7105941).

REPRODUCTION INSTRUCTIONS
-------------------------
The problem is re-creatable with the Java 2D demo. The problem seems to be more re-creatable when the resolution is reduced from a higher value to next lower value (e.g. change resolution from x=1600, y=900 to x=1440, y=900 ). The issue is rarely seen when the resolution is changed from a lower value to a higher value. It also may take up to several test runs or minimizes back and forth to manifest the hang.

1. java -jar /jdk1.8.0/demo/jfc/Java2D/Java2Demo.jar
2. Change screen resolution
3. Java 2D demo will be seen in hung state.

WORKAROUND
----------
If the application is minimized while the resolution is changed the deadlock does not occur.