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