RFR(S): 8153267: nmethod's exception cache not multi-thread safe
Andrew Haley
aph at redhat.com
Thu Apr 7 10:14:23 UTC 2016
On 07/04/16 10:08, Doerr, Martin wrote:
> atomic update for the _count would only be required if there were
> multiply threads which attempt to increment it
> concurrently. However, updates are under lock, so we only have
> concurrent readers which is ok.
>
> I still think “volatile” does what we need here. Especially the xlC
> compiler on AIX tends to reload variables from memory. Exactly this
> can be prevented by making the field volatile.
I think your latest patch is OK. Whether volatile is really good
enough, I don't know. The new(ish) C++ memory model treats this as a
race, and therefore undefined behaviour. Old C++ didn't have a memory
model, so the best we can do with racy code is guess about what our
compilers might do.
I certainly much prefer a release_store to the storestore fence used
in the fix for 8143897.
Andrew.
More information about the hotspot-compiler-dev
mailing list