RFR (S): 8223177: Data race on JvmtiEnvBase::_tag_map in double-checked locking

[David Holmes]

On 2/05/2019 11:00 am, Man Cao wrote:
> Thank everyone for the review!
> Renamed and final webrev:
> https://cr.openjdk.java.net/~manc/8223177/webrev.02/

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.

David
-----

> -Man
> 
> 
> 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.
> 
> 
>     Thanks,
>     Serguei
> 
> 
>     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
>>
>>     -Man
>