RFR(M): 8029101: PPC64 (part 211): ordering of Independent Reads of Independent Writes

Vladimir Kozlov vladimir.kozlov at oracle.com
Mon Nov 25 16:51:19 PST 2013


I have to ask David to do correctness evaluation.

I am fine with suggested changes because you did not change our current 
code for our platforms (please, do not change do_exits() now).
But may be it should be done using more general query which is set 
depending on platform:

OrderAccess::needs_support_iriw_ordering()

or similar to what we use now:

VM_Version::needs_support_iriw_ordering()

 From what I understand our ppc port is also affected. David?

In library_call.cpp can you add {}? New comment should be inside  else {}.

I think you should make _wrote_volatile field not ppc64 specific which 
will be set to 'true' only on ppc64. Then you will not need PPC64_ONLY() 
except in do_put_xxx() where it is set to true. Too many #ifdefs.

In do_put_xxx() can you combine your changes:

    if (is_vol) {
      // See comment in do_get_xxx().
#ifndef PPC64
      insert_mem_bar(Op_MemBarVolatile); // Use fat membar
#else
      if (is_field) {
        // Add MemBarRelease for constructors which write volatile field 
(PPC64).
        set_wrote_volatile(true);
      }
#endif
    }

Thanks,
Vladimir

On 11/25/13 8:16 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> I preprared a webrev with fixes for PPC for the VolatileIRIWTest of the torture test suite:
> http://cr.openjdk.java.net/~goetz/webrevs/8029101-0-raw/
>
> Example:
> volatile x=0, y=0
>    __________    __________    __________    __________
> | Thread 0 |  | Thread 1 |  | Thread 2 |  | Thread 3 |
>
>     write(x=1)    read(x)       write(y=1)    read(y)
>                   read(y)                     read(x)
>
> Disallowed:     x=1, y=0                    y=1, x=0
>
>
> Solution: This example requires multiple-copy-atomicity. This is only
> assured by the sync instruction and if it is executed in the threads
> doing the loads. Thus we implement volatile read as sync-load-acquire
> and omit the sync/MemBarVolatile after the volatile store.
> MemBarVolatile happens to be implemented by sync.
> We fix this in C2 and the cpp interpreter.
>
> This addresses a similar issue as fix "8012144: multiple SIGSEGVs
> fails on staxf" for taskqueue.hpp.
>
> Further this change contains a fix that assures that volatile fields
> written in constructors are visible before the reference gets
> published.
>
>
> Looking at the code, we found a MemBarRelease that to us, seems too strong.
> We think in parse1.cpp do_exits() a MemBarStoreStore should suffice.
> What do you think?
>
> Please review and test this change.
>
> Best regards,
>    Goetz.
>


More information about the ppc-aix-port-dev mailing list