JDK-8221120 : CopyOnWriteArrayList.set should always have volatile write semantics
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.concurrent
  • Affected Version: 11,13
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-03-20
  • Updated: 2020-04-08
  • Resolved: 2019-05-02
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 11 JDK 13
11.0.5Fixed 13 b20Fixed
Related Reports
Relates :  
Description
A user noticed that CopyOnWriteArrayList.set no longer does a volatile write when the new element is already present in its slot.

https://concurrency.markmail.org/thread/sdx7ehxrjqzrqmiy

Although such usage is questionable, and one can argue there is no guarantee of happens-before when the element is not in need of an update, and in practice no one will ever notice since the JVM is unlikely to optimize away the synchronized block in the method's implementation, nevertheless we should revert to an unconditional volatile write as seen in jdk8.
Comments
Seems to be introduced by JDK-8200258, which went to 11. 8u is not affected then.
25-07-2019

Fix Request (11u) Backporting this fix makes COWList do the right thing memory-semantics wise, and the same thing across all maintained JDK releases. The patch applies cleanly to 11u, passes tier1 and tier2 tests.
19-06-2019

Fix Request (11u) Backporting this fix makes COWList do the right thing memory-semantics wise, and the same thing across all maintained JDK releases. The patch applies cleanly to 11u, passes tier1 and tier2 tests.
19-06-2019