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

Doerr, Martin martin.doerr at sap.com
Mon Oct 12 09:39:16 UTC 2015

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,

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

Shi Hui

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

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,

-----Original Message-----
From: hotspot-compiler-dev [mailto:hotspot-compiler-dev-bounces at openjdk.java.net<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<mailto: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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/hotspot-compiler-dev/attachments/20151012/f919f461/attachment.html>

More information about the hotspot-compiler-dev mailing list