Possible subtle memory model error in ClassValue
Andrew Haley
aph at redhat.com
Fri Aug 7 16:52:37 UTC 2020
On 8/7/20 4:39 PM, David Lloyd wrote:
> However, I'm wondering if this isn't a side effect of what appears
> to be an incorrect double-checked lock at lines 374-378 of
> ClassValue.java [1]. In order for the write to the non-volatile
> `cache` field of ClassValueMap, it is my understanding that there
> must be some acquire/release edge from where the variable is
> published to guarantee that all of the writes are visible to the
> read site, and I'm not really sure that the exit-the-constructor
> edge is going to match up with with the synchronized block which
> protects a different non-volatile field. And even if my feeling
> that this is dodgy is valid, I'm not sure whether this NPE is a
> possible outcome of that problem!
It certainly doesn't look right to me. AFAICS this is classic broken
double-checked locking. It'd need some sort of fence after
constructing the ClassValueMap instance and before publishing it.
--
Andrew Haley (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the core-libs-dev
mailing list