RFR: 8186837: Memory ordering nmethod, _state and _stack_traversal_mark

[Roman Kennke]

Hi Robin,

I doubt that we can assume a symmetry between loadload and storestore like there is with load-acquire and release-store. This doesn't seem right. In my experience loadload and storestore are rather special purpose: loadload ensures ordering between otherwise unrelated loads and storestore likewise with stores.

And even symmetric use of load-acquire and release-store are often done wrong: those are not meant to protect concurrent access to the field, but to the stuff that is protected by the field access (think locks), I.e. what happens between the LA and RS. At least that is my understanding.

I suggest to do what David said and try to understand what concurrent accesses to which fields we have, and which fences are actually needed to ensure correct ordering.

And thanks for revisiting this!

Cheers, Roman

Am 29. August 2017 12:31:17 MESZ schrieb Robbin Ehn <robbin.ehn at oracle.com>:
>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/
>
>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
>
>Thanks Robbin

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20170829/34504f86/attachment.html>