RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses (original) (raw)

Vladimir Kozlov vladimir.kozlov at oracle.com
Thu Apr 16 23:04:15 UTC 2015

Because that code was added and tested only for boxed objects (goal of 6934604) - I wanted to avoid wider effects of those changes.

I think we can remove the limitation now in jd9 sources since we have enough time to tests it.

Regards, Vladimir

On 4/16/15 10:07 AM, Andrew Haley wrote:

On 02/18/2015 08:59 PM, Vladimir Kozlov wrote:

The code which eliminates MemBars for scalarized objects was added in jdk8:

http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/6f3fd5150b67 Right enough, but it only works with boxed objects. The Precedent of the MemBarNode is needed by MemBarNode::Ideal, and it's checked for: // Eliminate volatile MemBars for scalar replaced objects. if (canreshape && req() == (Precedent+1)) { ... think about eliminating the MemBar So if there's no Precedent, none of the barrier elimination is done. The only thing that sets the MemBar's Precedent is here: In parse::doputxxx // Preserve allocation ptr to create precedent edge to it in membar // generated on exit from constructor. if (C->eliminateboxing() && adrtype->isaoopptr() && adrtype->isoopptr()->isptrtoboxedvalue() && AllocateNode::Idealallocation(obj, &gvn) != NULL) { setallocwithfinal(obj); } The barrier is created in parse1, and uses allocwithfinal: if (method()->isinitializer() && (wrotefinal() || PPC64ONLY(wrotevolatile() ||) (AlwaysSafeConstructors && wrotefields()))) { exits.insertmembar(OpMemBarRelease, allocwithfinal()); So, it looks to me as though even the most trivial user-defined constructors with final fields will never eliminate barriers. I don't know what the thinking is here. Why does it matter whether the type being constructed is a boxed value? Andrew.

More information about the hotspot-dev mailing list