RFR(S): 8146828: Subsequent arraycopy does not always eliminate array zeroing
Roland Westrelin
roland.westrelin at oracle.com
Thu Feb 11 14:41:48 UTC 2016
http://cr.openjdk.java.net/~roland/8146828/webrev.00/
The problem is that we add a null check for src when we intrinsify arraycopy. So there's a null check between the allocation and the arraycopy itself and if we hit that null check we deoptimize with a live allocation and that allocation must be zeroed. We usually move the allocation below the predicates and arrange for the predicates in case they fail to resume execution in the interpreter right before the allocation. But in that case one of the predicate fails on a first compilation (subtype check) so we don't attempt it on the second one. In the change, the check for too many traps of type Reason_intrinsic and too many traps of type Reason_null_check are done independently so if we already hit too many Reason_intrinsic traps we still can move the null check above the allocation and eliminate zeroing. Hopefully I didn’t break anything in that very confusing code.
Roland.
More information about the hotspot-compiler-dev
mailing list