Possible subtle memory model error in ClassValue
hboehm at google.com
Tue Aug 18 15:50:05 UTC 2020
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
> > 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
of current and future implementations. Let's say I define a MutableInteger
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
preclude, and may not affect this anyway), I think this can be fairly
If we assume that MutableInteger somehow has a StoreStore barrier in its
initializing the MutableInteger and then storing a reference to it in the
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
either insert a fence, or not vectorize, to prevent this. With
MutableInteger, there is
no reason for it to do so.
More information about the core-libs-dev