-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8359266: Delete the usage of AppContext in the GraphicsDevice #25818
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
mrserb
wants to merge
2
commits into
openjdk:master
Choose a base branch
from
mrserb:JDK-8359266
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
+70
−28
Open
Changes from all commits
Commits
Show all changes
2 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
65 changes: 65 additions & 0 deletions
65
test/jdk/java/awt/GraphicsDevice/FullScreenWindowRace.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,65 @@ | ||
/* | ||
* Copyright Amazon.com Inc. or its affiliates. All Rights Reserved. | ||
* DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. | ||
* | ||
* This code is free software; you can redistribute it and/or modify it | ||
* under the terms of the GNU General Public License version 2 only, as | ||
* published by the Free Software Foundation. | ||
* | ||
* This code is distributed in the hope that it will be useful, but WITHOUT | ||
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | ||
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License | ||
* version 2 for more details (a copy is included in the LICENSE file that | ||
* accompanied this code). | ||
* | ||
* You should have received a copy of the GNU General Public License version | ||
* 2 along with this work; if not, write to the Free Software Foundation, | ||
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. | ||
* | ||
* Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA | ||
* or visit www.oracle.com if you need additional information or have any | ||
* questions. | ||
*/ | ||
|
||
import java.awt.GraphicsDevice; | ||
import java.awt.GraphicsEnvironment; | ||
import java.awt.Window; | ||
|
||
/** | ||
* @test | ||
* @key headful | ||
* @bug 8359266 | ||
* @summary Tests for a race condition when setting a full-screen window | ||
*/ | ||
public final class FullScreenWindowRace { | ||
|
||
public static void main(String[] args) throws InterruptedException { | ||
Window window = new Window(null); | ||
GraphicsDevice gd = GraphicsEnvironment.getLocalGraphicsEnvironment() | ||
.getDefaultScreenDevice(); | ||
|
||
Thread thread = new Thread(() -> { | ||
while (gd.getFullScreenWindow() == null) { | ||
// Busy wait - can be optimized away without volatile | ||
} | ||
}); | ||
|
||
thread.setDaemon(true); | ||
thread.start(); | ||
|
||
// Give thread some time to start and begin the loop | ||
Thread.sleep(2000); | ||
|
||
gd.setFullScreenWindow(window); | ||
|
||
thread.join(15000); | ||
|
||
boolean alive = thread.isAlive(); | ||
|
||
gd.setFullScreenWindow(null); | ||
window.dispose(); | ||
if (alive) { | ||
throw new RuntimeException("Full screen window is NOT detected!"); | ||
} | ||
} | ||
} |
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A
synchronized
block has stronger memory consistency guarantees than avolatile
modifier.Did you consider leaving the synchronized block but removing the usage of
AppContext
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you mean by stronger in this use case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean that there's a happens before relation each time the synchronized block is reach whereas with volatile, the happens before relation is guaranteed only when the value of the variable changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do not think that this is true "guaranteed only when the value of the variable changes".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly! A write to a volatile field.
Yet entering and leaving a synchronized block gives a happens-before relation each time.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I mean is two threads that called
GraphicsDevice.getFullScreenWindow
still established a happens-before relation for each call, which will be gone with the volatile modifier.It may be fine… or may be not… this is why I'm asking.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That only affects the case where the second thread tries to read shared data (unrelated to GraphicsDevice) without synchronization, which was written before the first thread called getFullScreenWindow(). If visibility is required, it should be ensured by the caller. Depending on some internal and undocumented lock for that is not a good thing.