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

[Vladimir Kozlov]

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 (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.
>