Possible subtle memory model error in ClassValue

[Hans Boehm]

On Wed, Aug 12, 2020 at 2:09 AM Andrew Dinn <adinn at redhat.com> 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?
>
I think it's potentially more common, though it clearly depends on the
details
of current and future implementations. Let's say I define a MutableInteger
class in
the expected way, and then want to say, copy every element to an int[].
At least if we naively ignore details like null checks (which I may be able
to statically
preclude, and may not affect this anyway), I think this can be fairly
easily vectorized
in SVE.

If we assume that MutableInteger somehow has a StoreStore barrier in its
constructor,
initializing the MutableInteger and then storing a reference to it in the
array,
while my copy function is running, can still result in the copy seeing
an uninitialized value.

If my example used Integer instead of MutableInteger, the compiler would
have to
either insert a fence, or not vectorize, to prevent this. With
MutableInteger, there is
no reason for it to do so.

Hans