Possible subtle memory model error in ClassValue

[Peter Levart]

Hi,


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:


https://github.com/openjdk/jdk/pull/7


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?


Regards, Peter


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?
>
> regards,
>
>
> 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
>