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.
