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