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

Andrew Haley aph at redhat.com
Thu Apr 16 17:07:44 UTC 2015

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 (can_reshape && 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::do_put_xxx

// Preserve allocation ptr to create precedent edge to it in membar
// generated on exit from constructor.
if (C->eliminate_boxing() &&
    adr_type->isa_oopptr() && adr_type->is_oopptr()->is_ptr_to_boxed_value() &&
    AllocateNode::Ideal_allocation(obj, &_gvn) != NULL) {
  set_alloc_with_final(obj);
}

The barrier is created in parse1, and uses alloc_with_final:

if (method()->is_initializer() && (wrote_final() || PPC64_ONLY(wrote_volatile() ||) (AlwaysSafeConstructors && wrote_fields()))) { _exits.insert_mem_bar(Op_MemBarRelease, alloc_with_final());

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