Possible subtle memory model error in ClassValue
hboehm at google.com
Wed Aug 19 16:55:06 UTC 2020
If I understand the code correctly, adding the fence should fix this for
current implementations. But it is not correct by current language rules,
and may conceivably break in the future unless the implementation enforces
On Wed, Aug 19, 2020 at 6:13 AM Galder Zamarreno <galder at redhat.com> wrote:
> On Mon, Aug 10, 2020 at 2:19 PM Doug Lea <dl at cs.oswego.edu> wrote:
> > Catching up...
> > As implied in other posts, the minimal fix is to add a trailing release
> > fence (using Unsafe?) to the constructor.
> FYI I have sent an RFR with the proposed fix ^
> > Or less delicately, to access
> > only using acquire/release (which will cost a bit on ARM/Power, but
> > probably not noticeable on x86), or most simply (but expensively) to
> > declare the field volatile.
> > Also, as Hans noted, the consensus seems to be that there not enough to
> > be gained by always adding a release fence to constructors. A few errors
> > like this might never occur, but other related anomalies with non-final
> > field accesses would remain.
> > -Doug
More information about the core-libs-dev