United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6658428 C2 doesn't inline java method if corresponding intrinsic failed to inline.
JDK-6658428 : C2 doesn't inline java method if corresponding intrinsic failed to inline.

Details
Type:
Bug
Submit Date:
2008-02-02
Status:
Resolved
Updated Date:
2013-06-26
Project Name:
JDK
Resolved Date:
2012-03-10
Component:
hotspot
OS:
solaris_9
Sub-Component:
compiler
CPU:
sparc
Priority:
P5
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
hs24 (b03)

Related Reports
Backport:
Backport:
Backport:
Relates:

Sub Tasks

Description
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.

                                    

Comments
PUBLIC COMMENTS

Is that only the case for LibraryCallKit::inline_string_indexOf() or are there more cases where this applies?
                                     
2009-02-13
PUBLIC COMMENTS

All intrinsics methods which return false can cause it. Assigning bug to you.
                                     
2010-11-09
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);
    }
}
                                     
2011-12-09
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.
                                     
2012-01-17
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.
                                     
2012-02-15
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.
                                     
2012-02-15
EVALUATION

http://hg.openjdk.java.net/hsx/hotspot-comp/hotspot/rev/b40ac3579043
                                     
2012-03-06
EVALUATION

http://hg.openjdk.java.net/lambda/lambda/hotspot/rev/b40ac3579043
                                     
2012-03-22



Hardware and Software, Engineered to Work Together