RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark

[David Holmes]

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