On 02/09/17 03:53, Hans Boehm wrote: > The problem is that all solutions that put all overhead on the writing side > are inherently not correct with respect to the Java memory model. They rely > on the necessary reader-side order (dataLayout read not reordered after > read of ClassDataSlots that use the dataLayout value) to be enforced (as > you would expect) by the data dependency. The Java memory model only > guarantees that (under the right conditions) for final fields. (This is > controversial, but "fixing" it opens another can of worms.) Here you would > be relying on it for dataLayout, a non-final field. > > I believe current implementations in fact enforce the necessary ordering. > But since it (surprisingly) appears to not be completely free to have > dependencies of this kind enforce memory visibility ordering (DEC Alpha > famously didn't), I wouldn't bet large sums of money on this statement > remaining true indefinitely on all relevant architectures.
Indeed, and I have my doubts about RISC V. But it seems to me that any processor architecture which broke dependency ordering in such a way would also require fences for every read, volatile or not, of reference type, would it not? Otherwise the basic security guarantees of the platform would not hold. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
