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

Hans Boehm hboehm at google.com
Thu Aug 31 19:39:54 UTC 2017


On Thu, Aug 31, 2017 at 5:13 AM, Aleksey Shipilev <shade at redhat.com> wrote:
>
...
>
> Does not work, and I assume it is broken on POWER. You need to read the
volatile variable in
> *another thread* to make this effective. Which means you have to have
$dataLayout volatile, getting
> you to square one.
>
> 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.

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.

> Thanks,
> -Aleksey
>


More information about the core-libs-dev mailing list