RFR: 8181085: Race condition in method resolution may produce spurious NullPointerException
Andrew Haley
aph at redhat.com
Thu May 25 14:07:45 UTC 2017
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.
More information about the jdk10-dev
mailing list