RFR(S): 8153267: nmethod's exception cache not multi-thread safe

[Doerr, Martin]

Hi Andrew,

there are many places in hotspot where we rely on ordering by address dependency. That sounds feasible to me since we're not supporting Alpha processors.
The load of the ExceptionCache pointer is only used to access elements of the cache, not to establish ordering of other accesses.

I don't think compilers are allowed to break anything here because I have made the field volatile. This prevents optimizers from reordering, optimizing out or duplicating some of the loads.
All supported processors respect the ordering (due to address dependency), too, so I believe we're ok.

I'm not sure if this is what you're concerned about. Did I miss anything?

Best regards,
Martin


-----Original Message-----
From: Andrew Haley [mailto:aph at redhat.com] 
Sent: Freitag, 1. April 2016 18:43
To: Doerr, Martin <martin.doerr at sap.com>; hotspot-compiler-dev at openjdk.java.net
Subject: Re: RFR(S): 8153267: nmethod's exception cache not multi-thread safe

On 04/01/2016 01:37 PM, Doerr, Martin wrote:

> Therefore, the nmethod's field _exception_cache needs to be volatile
> and adding new entries must be done by releasing stores. (Loading
> seems to be fine without acquire because there's an address
> dependency from the load of the cache to the usage of its contents
> which is sufficient to ensure ordering on all openjdk platforms.)

I think that's very risky.  We can't be really sure what an optimizer
might do in this area, as discussed at (very) considerable length in
concurrency forums.  memory_order_consume does this correctly in C++11
but we're not yet using C++11.  I'd use acquire and leave a note that
in future this can be replaced by memory_order_consume.

Andrew.