[9] RFR (S): 8148754: C2 loop unrolling fails due to unexpected graph shape

Zoltán Majó zoltan.majo at oracle.com
Mon Feb 15 16:45:03 UTC 2016


Hi Aleksey,


thank you for the feedback!

On 02/15/2016 04:40 PM, Aleksey Shipilev wrote:
> On 02/15/2016 06:22 PM, Zoltán Majó wrote:
>> The failure was triggered by Aleksey's Indify String Concatenation
>> changes but the generated bytecodes are valid. So this seems to be a
>> compiler issue that was previously there but was not yet triggered.
> Oh wow, but ISC does not do anything heavy (yet) -- the bytecode is the
> same as javac produces, except that we generate a separate method and
> then @ForceInline it through j.l.i.CallSite -- which puzzles me why ISC
> had triggered this.

The failure started to appear in the compiler nightlies just after we 
have pulled down hs-main. There are lots of changes there and I cannot 
point to ISC as being the cause with 100% confidence. Sorry for the 
inaccuracy in my original text.

However, a the pre-ISC build inlines a different set of methods than a 
post-ISC build when compiling

IeeeRecommendedTests::testFloatBooleanMethods

In the post-ISC build, two of the methods inlined into 
testFloatBooleanMethods()

static jint Tests.test(jobject, jfloat, jint, jint)
static jint Tests.test(jobject, jfloat, jdouble, jfloat, jfloat)

contain invokedynamic calls to makeConcatWithConstants().

So, as I mentioned, I don't think ISC is at fault here as the bytecodes 
look fine to me. But maybe the body/annotation of some inlined methods 
has slightly changed due to ISC. As a result, inlining is performed 
differently, which, I suspect, results in the bug being triggered.

One would have to investigate further to confirm/disprove the above 
hypothesis.

Best regards,


Zoltan

>
>> Webrev:
>> http://cr.openjdk.java.net/~zmajo/8148754/webrev.00/
> Anyhow, the explanation and the patch looks fine to me.
>
> -Aleksey
>
>



More information about the hotspot-compiler-dev mailing list