[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