RFR: 8187033: [PPC] Imporve performance of ObjectStreamClass.getClassDataLayout()
aph at redhat.com
Sat Sep 2 08:26:42 UTC 2017
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.
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the core-libs-dev