Bug ID: JDK-6658428 C2 doesn't inline java method if corresponding intrinsic failed to inline.

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 7	JDK 8	Other
7u40Fixed	8Fixed	hs24Fixed

Add the check that a corresponding intrinsic will be inlined into the current code
and inline the java method if the check failed.

Currently checks are done too late, when C2 tries to inline intrinsic, for example:

LibraryCallKit::inline_string_indexOf() {
...
  // don't intrinsify if argument isn't a constant string.
  if (!argument->is_Con()) {
    return false;
  }

And if checks fail it is too late to inline java method.

EVALUATION http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b40ac3579043
22-03-2012
EVALUATION http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b40ac3579043
06-03-2012
SUGGESTED FIX Adding an allow_intrinsic argument to the callgenerator constructor. And creating a fallback that uses that flag when the intrinsic-call expansion return false. Also adding test of usePopCount flag for leading/trailing_zero_count in make_vm_intrinsic. Unfortunatly this introduces an ifdef #SPARC in platform independent code, but I think it is a good idea to be consistent and never create intrinsics that is guaranteed to fail. That is how it is done for all other intrinsics. Also improves the inline-logging a bit.
15-02-2012
EVALUATION This bug is caused by intrinsics that may return false when expanding at a call site. There is no fallback for creating a plain java generator. There are at leat two cases when this happens: 1) Plain old boyer-moore string-index-of transformation when the pattern argument is not constant 2) Leading/Trailing-zero-count intrinsics on sparc when the popcount instruction is unavailable #2 is unneccessary, for every other intrinsic that relies on hardware support, we check the corresponding flag in make_vm_intrinsic. For Leadint/Trailing-zero-count that is done in the intrinsic expansion instead with the platform dependent match_rule_supported call. But then the intrisic is already created.
15-02-2012
PUBLIC COMMENTS So, for an intrinsic that return false, we will get a non-intrinsic call-generator that we run as backup. Will add parameter to call_generator that prevents it from returning a intrinsic-generator and gives us the java-version instead. Looks like a minor change, but must be on the look out for side effects.
17-01-2012
PUBLIC COMMENTS Running this test case on SPARC fails: $ java -XX:-TieredCompilation -XX:+PrintCompilation -XX:+PrintInlining -XX:-UsePopCountInstruction test public class test { public static void main(String[] args) { Integer.valueOf(123); // load the Integer class int sum = 0; for (int i = 0; i < 100_000; i++) { sum += foo(i); } System.out.println(sum); } static int foo(int i) { return Integer.numberOfLeadingZeros(i); } }
09-12-2011
PUBLIC COMMENTS All intrinsics methods which return false can cause it. Assigning bug to you.
09-11-2010
PUBLIC COMMENTS Is that only the case for LibraryCallKit::inline_string_indexOf() or are there more cases where this applies?
13-02-2009