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

[coleen.phillimore at oracle.com]

On 3/25/19 8:34 PM, David Holmes wrote:
> Hi Coleen,
>
> On 26/03/2019 3: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
>
> How expensive is it to create OopMapCache? Are we likely to encounter 
> a lot of contention on this?
>
> As I mentioned in my reply to Dean I think it mildly preferable to use 
> cmpxchg if you want to use the value in case you lose the race:
>
> OopMapCache * temp = Atomic::cmpxchg(oop_map_cache, &_oop_map_cache, 
> NULL)
> if (temp != NULL) {
>   // Some other thread won.
>   delete oop_map_cache;
>   oop_map_cache = temp;
> }

I was curious if this was the case, or if I needed a load_acquire. That 
said, this is not expensive at all, and probably not worth doing.  I 
thought that the only benefit would be to remove one of our mutexes, 
particularly since this one can be used by both java threads and 
non-java threads.

I'm going to withdraw this and make the original bug to work on the 
DerivedPointerTableGC_lock instead.

thanks,
Coleen
>
> Thanks,
> David
>
>> Thanks,
>> Coleen