RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark
david.holmes at oracle.com
Tue Aug 29 12:35:42 UTC 2017
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).
This seems okay to me.
> It's not clear in this code if there other concurrent dependent
> 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 Robbin
More information about the hotspot-compiler-dev