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