[aarch64-port-dev ] RFR: Elide more final field's write memory barrier with escape analysis result

[Hui Shi]

Thanks Roland and Martin!

Agree, it's better remove extra code for PPC64.  new webrev
http://cr.openjdk.java.net/~hshi/8138956/webrev_v2/
comments below

Regards
Shi Hui

On 10 October 2015 at 00:17, Doerr, Martin <martin.doerr at sap.com> wrote:

> Hi,
>
> I basically like this change. Thanks for pointing me to it.
>
> But I don't like the extra code for PPC64. If the allocation does not
> escape globally it should be safe to elide the membar regardless of whether
> we wrote final or volatile fields.
>
>
Difference is final field is always belonging to initializing object while
volatile field isn't. It's reasonable to insert MemoryBarrier, when
volatile field is written in its owning class' initializer method, like you
example of AtomicInteger.

In following example, class A initiailzer writes both final field and
volatile field, suppose A instance doesn't escape. MemBarRelase is inserted
because final and volatile field wirte. Writing b.vol in A's initializer is
same with writing b.vol in none-initalizer method and doesn't need
MemBarRelease in my understanding.

1. If final and volatile field from same allocation,
elide MemBarRelase when allocation doesn't escape is safe.
2. If volatile field doesn't belong to final field's allocation object,
MemBarRelase for volatile is not necessary.
So it's safe to remove MemBarRelease when final field's allocation object
doesn't escape.

Class A {
      final int a;
      A(int val, B b) { a=val; b.vol = val; }
}

Class B { volatile int vol;}



> Please also note that PPC64_ONLY(...) NOT_PPC(...) is incorrect on PPC32.
>
> Actually, it's ugly that PPC64_ONLY was used here. Should better be
> (support_IRIW_for_not_multiple_copy_atomic_cpu && wrote_volatile()), but
> that's not the topic of this change.
>
> Best regards,
>   Martin
>
>
> -----Original Message-----
> From: hotspot-compiler-dev [mailto:
> hotspot-compiler-dev-bounces at openjdk.java.net] On Behalf Of Roland
> Westrelin
> Sent: Donnerstag, 8. Oktober 2015 13:51
> To: Hui Shi
> Cc: hotspot compiler; aarch64-port-dev at openjdk.java.net
> Subject: Re: RFR: Elide more final field's write memory barrier with
> escape analysis result
>
> > http://cr.openjdk.java.net/~hshi/8138956/webrev/
>
> The code change looks good to me. The comments have a few typos and are a
> bit confusing. I'll tweak them before I push it.
>
> PPC folks, in case you missed it, parse1.cpp has a ppc related fix.
>
> Roland.
>