Possible subtle memory model error in ClassValue
peter.levart at gmail.com
Sat Aug 15 08:37:16 UTC 2020
There might be a way to fix this NPE without adding additional memory
fences. The CacheValueMap.cacheArray field is not final because it can
change during lifetime of CacheValueMap - it holds an array of entries
which can get resized (replaced with bigger array) which is performed
while holding a lock on the CacheValueMap instance. So I thought: why
couldn't the field be null initially and its value initialized in a
similar way as it is replaced with bigger array now. If I got this
correct, it would take the following changes:
The fast-path now trades an explicit null check for a null check that
throws NPE when dereferencing cache array, so it should probably have no
effect on performance (benchmarks pending).
So, what do you think?
On 8/12/20 11:08 AM, Andrew Dinn wrote:
> On 11/08/2020 18:06, Hans Boehm wrote:
>> I think the relevant statement is:
>> "An address dependency between two reads generated by SVE vector load
>> instructions does not contribute to the Dependency-ordered-before relation."
>> This is only an issue if BOTH loads are SVE loads. In particular
>> reference loads have to be vectorized for this to matter, which I expect
>> is not the common situation. I have not explored this in great detail,
>> but it should suffice to put fences between two dependent vector
>> reference loads, and between a reference load and a dependent final
>> field load.
> Hmm, so this might perhaps be an issue with something like a deep copy
> of an int, where loading of successive int references might be
> vectorized using SVE instructions and processing of the contents of each
> referenced int might also be similarly vectorized. In that case the
> loading of the int contents would need to be ordered wrt the load of the
> int references using a LoadLoad barrier?
> Andrew Dinn
> Red Hat Distinguished Engineer
> Red Hat UK Ltd
> Registered in England and Wales under Company Registration No. 03798903
> Directors: Michael Cunningham, Michael ("Mike") O'Neill
More information about the core-libs-dev