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

[serguei.spitsyn at oracle.com]

Hi David and Nan,

Sorry, my suggestion was not aligned with usual practice and added some 
extra work. :(

Thanks,
Serguei


On 5/1/19 19:42, David Holmes wrote:
> 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
>>