8359266: Delete the usage of AppContext in the GraphicsDevice

[mrserb]

This PR removes the usage of AppContext from the GraphicsDevice class. The original use case was to store the full-screen window in some AppContext, which was necessary in the context of plugin/appletviewer environments. However, there is now effectively only one main AppContext, so this indirection can be eliminated.

Notes: GraphicsDevice provides two methods for handling full-screen windows:

• setFullScreenWindow() is considered thread-safe, as all platform-specific implementations override it with synchronized methods (example).
• getFullScreenWindow() previously relied on AppContext for thread-safety. After removing AppContext, this method is now made thread-safe by declaring the fullScreenWindow field as volatile. This change has been validated by an added test.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8359266: Delete the usage of AppContext in the GraphicsDevice (Enhancement - P3)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/25818/head:pull/25818
$ git checkout pull/25818

Update a local copy of the PR:
$ git checkout pull/25818
$ git pull https://git.openjdk.org/jdk.git pull/25818/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 25818

View PR using the GUI difftool:
$ git pr show -t 25818

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/25818.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back serb! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

❗ This change is not yet ready to be integrated.
See the Progress checklist in the description for automated requirements.

[openjdk]

@mrserb The following label will be automatically applied to this pull request:

• client

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[mlbridge]

Webrevs

• 00: Full (f4856925)

[aivanov-jdk]

A synchronized block has stronger memory consistency guarantees than a volatile modifier.

Did you consider leaving the synchronized block but removing the usage of AppContext?

[mrserb]

What do you mean by stronger in this use case?

[aivanov-jdk]

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.

[mrserb]

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.

I do not think that this is true "guaranteed only when the value of the variable changes".

A write to a volatile field (§8.3.1.4) happens-before every subsequent read of that field.

[aivanov-jdk]

Exactly! A write to a volatile field.

Yet entering and leaving a synchronized block gives a happens-before relation each time.

[aivanov-jdk]

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.

[mrserb]

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.

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.