RFR(M): Memory ordering in taskqueue.hpp
David Holmes
david.holmes at oracle.com
Mon Dec 17 16:23:36 PST 2012
Hi Goetz,
On 17/12/2012 10:58 PM, Lindenmaier, Goetz wrote:
> Hi,
>
> Once more, with webrev:
> http://cr.openjdk.java.net/~goetz/webrevs/webrev-taskqueue/
I can see that this function needs a storestore barrier:
237 void set_empty() {
238 _bottom = 0;
239 _age.set(0);
240 }
to preserve ordering. Are there other functions to which we can
constrain the loadload and storestore barriers rather than using the
setters/getters the way you have defined? This is always about a pair
(sometimes groups) of accesses so I'd rather deal with the pairs than
treat each field as if it were a Java volatile.
Thanks,
David Holmes
> Sorry for that.
>
> I would like to contribute fixes wrt. memory ordering in taskqueue.hpp.
>
> On Platfoms with weak memory ordering the taskqueue is not accessed
> properly, as the accesses to the fields _bottom and _age are not ordered
> correctly. Volatile is not sufficient to enforce this, because it depends on
> what the compiler assumes to be necessary for volatile variables.
>
> The fix is to pull getter/setter routines from Age to TaskQueueSuper and use methods from
> OrderAccess to access the fields in _age as well as _bottom. Further the code must always
> use the getter/setter methods to access _bottom, _age or the subfields of _age.
> On the other hand we can relax constraints for accesses to locals oldAge and newAge.
>
> The OrderAccess routines do simple load/stores on x86_64.
>
> I want to discuss this change here and would like very much to see it taking
> it's way into OpenJDK to support ports on platforms with weak memory
> ordering, and, in particular, our PPC port.
>
> Best regards,
> Goetz.
>
>
More information about the hotspot-dev
mailing list