RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking
david.holmes at oracle.com
Thu May 2 02:42:50 UTC 2019
On 2/05/2019 11:00 am, Man Cao wrote:
> Thank everyone for the review!
> Renamed and final webrev:
No do not rename! Sorry Serguei but for these accesses with OrderAccess
semantics the placement of the acquire/release reflects the barrier
semantics of load_acquire and release_store. So we use foo_acquire to
load foo with acquire semantics; while release_set_foo performs a
release barrier followed by set_foo. This convention is used throughout
the VM for these kinds of methods.
> On Wed, May 1, 2019 at 5:21 PM serguei.spitsyn at oracle.com
> <mailto:serguei.spitsyn at oracle.com> <serguei.spitsyn at oracle.com
> <mailto:serguei.spitsyn at oracle.com>> wrote:
> Hi Man,
> Looks good to me.
> Minor comment:
> I'd suggest to rename tag_map_acquire to acquire_tag_map to be
> consistent with release_set_tag_map.
> On 4/30/19 18:51, Man Cao wrote:
>> Hi all,
>> Can I have reviews for this small change that adds memory fences
>> for double-checked locking?
>> We found this race while working on the Java ThreadSanitizer project.
>> Webrev: https://cr.openjdk.java.net/~manc/8223177/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8223177
More information about the serviceability-dev