RFR (S) 8160539: Stack frame scanning acquires several mutexes

[David Holmes]

Hi Dean,

On 26/03/2019 10:14 am, dean.long at oracle.com wrote:
> Is it OK to do a normal read of _oop_map_cache here:
> 
> +    if (!Atomic::replace_if_null(oop_map_cache, &_oop_map_cache)) {
> +      // Some other thread won.
> +      delete oop_map_cache;
> +      oop_map_cache = _oop_map_cache;
>       }
> 
> or does it need to be load-acquire or volatile?  We don't want the 
> compiler to use the value from the earlier read:

 From atomic.hpp:
  // All of the atomic operations that imply a read-modify-write action
  // guarantee a two-way memory barrier across that operation.

So semantically the above should be correct (some platforms have bugs 
where the barrier is missing when the CAS fails). That said it would 
seem preferable to me to use cmpxchg if we actually want to use the 
value when we lose the race.

Cheers,
David
-----


> 
>     OopMapCache* oop_map_cache = 
> OrderAccess::load_acquire(&_oop_map_cache);
> 
> 
> dl
> 
> On 3/25/19 10:49 AM, coleen.phillimore at oracle.com wrote:
>> Summary: Use CAS instead of OopMapCacheAlloc_lock
>>
>> Tested with hs-tier1-5 and specjbb2017.
>>
>> open webrev at http://cr.openjdk.java.net/~coleenp/2019/8160539.01/webrev
>> bug link https://bugs.openjdk.java.net/browse/JDK-8160539
>>
>> Thanks,
>> Coleen
>