RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException

[Andrew Haley]

On 25/05/17 14:57, Andrew Dinn wrote:
> On x86 the release_store_ptr operation just reduces to an assignment of
> volatile field _indices. That alone doesn't stop the compiler
> re-ordering it before the assignment of f1. Making both fields volatile
> does stop them being re-ordered.

Please bear with me.  We have to set f1 and then bytecode_1.  We do not
want the store to bytecode_1 to move before the store to f1.

OrderAccess::release_store_ptr() should be strong enough to guarantee that,
regardless of whether f1 is volatile or not.
If it's not, there should be a compiler fence in release_store_ptr().

Andrew.