RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()

[Andrew Haley]

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