RFR: 8364434: Inconsistent BufferedContext state after GC [v4]

[Jayathirth D V]

On Mon, 11 Aug 2025 15:48:58 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

>> For "true" null objects, reset the ref itself to null. Non-null ref with null content means that the object was GC'ed. GC'ed state always behaves as not-equal to the new one, causing corresponding ops to be written into RQ.
>> 
>> Although I could not find practical scenarios where refs other than `validPaintRef` could cause problems, this is generally fragile and potentially problematic for any state object kept in weak ref. Therefore I changed the usage of all weak refs in the same way.
>
> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8364434: Inconsistent BufferedContext state after GC
>   
>   Restrict test to macOS

Yes the test if run on linux fails in CI because of Color not getting GC'ed. Adding sleep after each GC also doesn't help(This is done in some other tests which rely on System.gc())
 
Since System.gc() is just a hint to JVM, How about passing the test after trying for MAX_ITERATIONS and not making the test specific to mac? Because this test might start failing intermittently in some scenarios which are not under our control.

test/jdk/java/awt/ColorClass/WeakColorTest.java line 24:

> 22:  */
> 23: 
> 24: import java.awt.*;

Better to expand wild card imports.

-------------

PR Review: https://git.openjdk.org/jdk/pull/26576#pullrequestreview-3109991257
PR Review Comment: https://git.openjdk.org/jdk/pull/26576#discussion_r2269531170