RFR 8202201: All oop stores in the x64 interpreter are treated as volatile when using G1

[David Holmes]

Hi Coleen,

Wow. Have you run any performance tests to see what we've gained by 
eliding all the unnecessary "lock addl" psuedo-mfence?

On 15/09/2018 1:44 AM, coleen.phillimore at oracle.com wrote:
> Summary: ran out of registers, generated volatile and non-volatile 
> branches.
> 
> open webrev at http://cr.openjdk.java.net/~coleenp/8202201.01/webrev

Generally looks good. Your webrev seems to have picked up some noise 
from Mikael's unused Label changes ??

One query. Can you comment on the change to the 32-bit code where we no 
longer use MO_RELAXED for the store? I'm assuming this is just a 
potential optimization in the case that the store might be ordered 
somehow by default. Though why this would be 32-bit specific I don't know.

Thanks,
David

> bug link https://bugs.openjdk.java.net/browse/JDK-8202201
> 
> Tested with applications/jcstress, tier1&2 and jvmti tests (sometimes 
> they filled up interpreter fixed space).
> 
> putfield bytecode size is 2176 bytes now, 1248 bytes before
> putstatic bytecode size is 1344 bytes now, 864 before
> fast_xputfield is same 96 bytes.
> 
> Thanks,
> Coleen
>