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

Doerr, Martin martin.doerr at sap.com
Fri Oct 9 16:17:37 UTC 2015


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.

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.


More information about the hotspot-compiler-dev mailing list