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
