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

[Aleksey Shipilev]

On 08/31/2017 09:39 PM, Hans Boehm wrote:
>> I guess you can make VarHandle.fullFence() between getClassDataLayout0() and storing it to the 
>> non-volatile field...
> 
> ... with the usual warning about this sort of thing:
> 
> According to the JMM, it's not guaranteed to work, because the reader-side guarantees are not
> there. In practice, you're relying on dependency-based ordering, which the compiler is currently
> unlikely to break in this case. But future implementations may.

Right.

> I presume the real concern here is the cost on the reader side? Presumably that could be reduced 
> with a VarHandle getAcquire(). I believe that eliminates the heavy-weight sync, and just keeps
> an lwsync. Imperfect, but better.
Oh right! This is exactly why acq/rel exist. Since OSC is a heavily used class, the Unsafe
counterparts might be better:

private static final Unsafe U = ...;
private static final long CDS_OFFSET = U.objectFieldOffset(...);

private volatile ClassDataSlot[] dataLayout; // volatile for safety of naked reads

ClassDataSlot[] getClassDataLayout() throws InvalidClassException {
  ClassDataSlot[] slots = U.getObjectAcquire(this, CDS_OFFSET);
  if (slots == null) {
    slots = getClassDataLayout0();
    U.putObjectRelease(this, CDS_OFFSET, slots);
  }
  return slots;
}

Ogata, please try if that indeed helps on POWER?

Thanks,
-Aleksey