Ping: RFR: JDK-8205523: Explicit barriers for interpreter

[Andrew Haley]

On 06/27/2018 11:02 AM, Erik Österlund wrote:

> I think that for the non-GC developers, it gets more tricky if they
> have to remember not to perform any writes because somewhere further
> up in the call hierarchy, the oop was only resolved for reading. Or
> that any reads used have to be non-volatile, or you risk running
> into a subtle IRIW situation (even on TSO hardware) due to having
> multiple reads riding on the same read resolve, potentially causing
> inconsistencies. It won't be a problem in the places you inserted
> the read resolves to now.

It would be correct to resolve everything for writes, but would not
help performance, and we're trying to improve performance, not make it
worse.

With respect to volatility, read and write barriers mean that
developers have to pay attention to volatility.  But that's already
true even for TSO: for example, you can't hoist the result of a
volatile read into a register and use it again.  Given that non-GC
developers have to be aware of volatility anyway, what would be hurt
by having to mark volatile reads?  I would argue that it would make
code more explicit and thus more maintainable, and we have to do it in
all of the C++ code anyway.  Sure, this is a new discipline for x86
HotSpot developers.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671