RFR: 8073093: AARCH64: C2 generates poor code for ByteBuffer accesses

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) {

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?


More information about the core-libs-dev mailing list