RFR: 8158854: Ensure release_store is paired with load_acquire in lock-free code
david.holmes at oracle.com
Thu Aug 18 02:50:13 UTC 2016
Generally speaking release_store should be paired with load_acquire to
ensure correct memory visibility and ordering in lock-free code (often
the read path is what is lock-free). So based on some observations from
earlier bug fixes this bug was intended to examine the use of
release_store and see if we have the appropriate load_acquire as well.
The bug report lists all of the cases that were examined - some clear
cut correct, some complex correct, some fixed here and some split out
into separate issues.
Here's a summary of the actual changes in the webrev:
- next() accessor needs to use load_acquire.
- load of _verify_byte_codes_fn needs to load_acquire to pair with use
- release_store of _is_new_verify_byte_codes_fn is not needed
The logic for storing dimensions values was using a storeStore barrier
between the lower and higher dimensions. This is converted to use a
release-store setter for higher-dimension, with paired load-acquire
accessor. Plus the accessed fields are declared volatile.
The methods_jmethod_ids_acquire() and its paired
release_set_methods_jmethod_ids(), are moved to the .inline.hpp file
where they belong.
Updated declaration for _array_klasses now it is volatile.
More information about the hotspot-runtime-dev