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