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) {
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 core-libs-dev
mailing list