RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark

[Robbin Ehn]

Thanks David!

/Robbin

On 08/29/2017 02:35 PM, David Holmes wrote:
> Hi Robbin,
> 
> On 29/08/2017 8:31 PM, Robbin Ehn wrote:
>> Hi please review,
>>
>> The issue 8180932 - "Parallelize safepoint cleanup" changed _stack_traversal_mark to load acquire/store release, this is at least half wrong.
>> Instead for simplicity the write side storestore fence should be match with loadload on read side and the changes to _stack_traversal_mark undone (kept it volatile).
>>
>> Bug:
>> https://bugs.openjdk.java.net/browse/JDK-8186837
>>
>> Code:
>> http://cr.openjdk.java.net/~rehn/8186837/hotspot.01/webrev/
> 
> This seems okay to me.
> 
>> It's not clear in this code if there other concurrent dependent read/writes.
>> Is true that only when reading/writing _state and _stack_traversal_mark proper memory ordering is needed?
>> To track that I created: https://bugs.openjdk.java.net/browse/JDK-8186839
> 
> Okay. We need to understand how concurrent lock-free accesses can occur to ensure we have the right ordering constraints in place.
> 
> Thanks,
> David
> 
>> Thanks Robbin