[14] RFR(M): 8229496: SIGFPE (division by zero) in C2 OSR compiled method
Tobias Hartmann
tobias.hartmann at oracle.com
Wed Aug 28 13:14:34 UTC 2019
Hi,
please review the following patch:
https://bugs.openjdk.java.net/browse/JDK-8229496
http://cr.openjdk.java.net/~thartmann/8229496/webrev.00/
A DivI/ModINode loses direct control dependency to its div != 0 check (but remains being dominated
by it) and is then moved to before that check by PhaseIdealLoop::dominated_by() because
depends_only_on_test() is true.
Details:
- The inner do-while loop is unswitched based on the div != 0 check added by
GraphKit::zero_check_int() when parsing the irem/idiv bytecode.
- The div == 0 loop is always throwing an arithmetic exception (loop is removed), the div != 0 loop
computes 1 % div where the ModI is not directly control dependent on the div != 0 check anymore (but
on the preceding array store check).
- Loop predicates are added to the outer loop in PhaseIdealLoop::loop_predication_impl_helper() and
since the ModI is control dependent on the array store range check once that one is converted to a
predicate, PhaseIdealLoop::dominated_by() moves the ModI up as well because depends_only_on_test()
is true:
http://hg.openjdk.java.net/jdk/jdk/file/cb836bd08d58/src/hotspot/share/opto/loopopts.cpp#l272
- As a result, ModI is moved to before the outer loop while the div != 0 check from unswitching is
before the inner loop(s).
I've discussed this with Roland and he suggested adding a CastNode to keep the dependency between
the div/mod operation and the zero check. I had to add a CastLLNode to implement this for long
div/mod as well.
Thanks,
Tobias
More information about the hotspot-compiler-dev
mailing list