[9] RFR(S): 8179678: ArrayCopy with same src and dst can cause incorrect execution or compiler crash
Roland Westrelin
rwestrel at redhat.com
Mon May 22 16:26:34 UTC 2017
> Call nodes have complicated graph of following control
> projections. You don't check for them. Why? I think that was the
> reason that we scan memory edges instead of control when searching for
> calls.
Catch and CatchProj?
The logic I changed handles an array copy, once it is expanded, whose
destination is a non escaping array.
Escape analysis only considers the destination of "validated" array
copies as non escaping:
PointsToNode::EscapeState es = PointsToNode::ArgEscape;
if (call->is_ArrayCopy()) {
ArrayCopyNode* ac = call->as_ArrayCopy();
if (ac->is_clonebasic() ||
ac->is_arraycopy_validated() ||
ac->is_copyof_validated() ||
ac->is_copyofrange_validated()) {
es = PointsToNode::NoEscape;
}
}
An array copy is "validated" when LibraryCallKit::inline_arraycopy()
inserted guards to validate that this arraycopy is a "good" arraycopy.
In PhaseMacroExpand::generate_arraycopy() the stub calls that are
inserted are all connected through a single ProjNode to the result
Region except:
1- the slow arraycopy call which has Catch and CatchProj nodes. But with
validated arraycopies, there shouldn't be a slow arraycopy alone but at
least one stub call on one of the control path.
2- a checkcast arraycopy for which the return of the call needs to be
checked: checkcast arraycopy are explicitly skipped for validated
arraycopies.
3- if the copy size is null, PhaseMacroExpand::generate_arraycopy()
would generate no call but that special case should be handled by
ArrayCopyNode::Ideal.
4- A generic arraycopy (if C2 can't tell whether inputs to arraycopy are
arrays).
I found that 4 can happen eventhough given the arraycopy is validated,
it could be avoided. So here is a new webrev which sets src_elem =
dest_elem in PhaseMacroExpand::expand_arraycopy_node() when dest_elem is
known and the arraycopy is validated.
http://cr.openjdk.java.net/~roland/8179678/webrev.03/
Roland.
More information about the hotspot-compiler-dev
mailing list