RFR(S): 8166836: Elimination of clone's ArrayCopyNode may make compilation fail silently
rwestrel at redhat.com
Wed Sep 28 09:30:03 UTC 2016
For a non escaping allocation, the logic that eliminates a clone's
ArrayCopy node, adds loads for each field of the eliminated allocation
at safepoints. For each load, the load's control is set so the load is
after the memory barrier that always precedes the ArrayCopy node but the
memory edge is set to the memory state before the memory barrier. Anti
dependency edges are added to the load nodes resulting in a graph that
can't be scheduled and a compilation that always fail.
I think the memory edges of the loads bypass the memory barrier so the
loads have a chance to be optimized out (if for instance the loads are
from a just allocated object). But that code doesn't seem to even work
in simple cases. Instead, I propose we eliminate the memory barrier
before the ArrayCopy node (and the one after).
It's quite unfortunate that this wasn't found by testing because
compilations where the graph is non schedulable simply fail. This could
have gone unnoticed much longer. In debug builds shouldn't we abort the
VM in C2Compiler::compile_method() if the compilation fails because of a
non schedulable graph?
More information about the hotspot-compiler-dev