RFR (S): 7177917: Failed test java/lang/Math/PowTests.java

Roland Westrelin roland.westrelin at oracle.com
Thu Jun 21 05:21:51 PDT 2012

The current intrinsics for pow and exp in c2 do not handle all cases and may trigger uncommon traps. When that happens, the next compilations won't attempt to use the intrinsic code and rather will fallback to inlining the java implementations of pow or exp which call the StrictMath implementation. So a java application could get different results for the same computation (either the intrinsic version or the StrictMath version). This is solved by never triggering uncommon traps in the intrinsic pow/exp but rather call the runtime on corner cases (similar to the interpreter/c1 code).
A similar problem could show up if ConditionalMoveLimit=0: c2 wouldn't use the same implementation as the interpreter/c1. So we can't offer to bail out if ConditionalMoveLimit is 0.
In inline_pow, the else branch of:
if( jvms()->depth() >= 1 ) {
was never tested (because we forbid compilation of pow as a standalone method) and had several problems that this change fixes.

An alternate fix would have been to simply forbid the inlining of the java implementation of pow/exp when intrinsification fails.



More information about the hotspot-compiler-dev mailing list