RFR: Elide more final field's write memory barrier with escape analysis result

[Hui Shi]

Thanks Martin!

Roland, would you please run JPRT test and sponsor this change?

Regards
Shi Hui

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

> Hi Hui Shi,
>
>
>
> thanks for the update. Looks good for PPC64 as well, now.
>
> As you already explained, the MemBarRelease is only relevant for fields of
> the allocated object. Hence, the final and volatile cases can be handled
> the same way.
>
>
>
> Best regards,
>
>   Martin
>
>
>
>
>
> *From:* Hui Shi [mailto:hui.shi at linaro.org]
> *Sent:* Samstag, 10. Oktober 2015 15:25
> *To:* Doerr, Martin
> *Cc:* Roland Westrelin; hotspot compiler;
> aarch64-port-dev at openjdk.java.net
>
> *Subject:* Re: RFR: Elide more final field's write memory barrier with
> escape analysis result
>
>
>
> 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151014/6116b79b/attachment.html>