Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8293798

Fix test bugs due to incompatibility with -XX:+AlwaysIncrementalInline

    XMLWordPrintable

Details

    • b16

    Backports

      Description

        A number of tests seem to fail in combination with compile flag "-XX:+AlwaysIncrementalInline".

        compiler/uncommontrap/Decompile.java
           java.lang.RuntimeException: Wrong compilation status.: expected false to equal true
           Quick Analysis: it seems that we don't to bimorphic inlining of function calls (2 static inlinings, uncommon_trap for others). Instead, we create two LateInlineCallGenerator, one for a class (hit), and one for the other cases (miss). LateInlineCallGenerator has is_inline false, so we do not go into the bimorphic inlining case (would require both receivers to have is_inline true). Instead, we generate a static call for one class (hit), and a virtual call for the rest (miss). Therefore, when the third class comes along the function does not trap, and not deopt either.
            For now, we will just deactivate the flag in the test. But more discussion is required if we want this flag to change the inline behavior in this way.

        compiler/intrinsics/klass/CastNullCheckDroppingsTest.java
            java.lang.AssertionError: compilation must not get deoptimized
            Seems usually we don't put the null_check with a trap, but with this flag we do have a null_check trap, which then triggers (with mark_non_entrant -> deopt). And the test expects that there is no deoptimization.
            Closer Analysis:
            We are in GraphKit::gen_checkcast.
            We have a cast that is wrapped in a MethodHandle. Normally, this would get directly inlined, and the output is deduced to be String*. With the flag, however, we do not inline, but create a JavaStaticCall, which represents invokeExact. This has 4 Object* inputs and 1 Object* output. So now the result of the cast is a Object*.
            Now we have a String* in the normal case, and Object* in the flag case. We now do a local cast to String*. For that we first check subtyping.
            switch (C->static_subtype_check(tk, objtp->as_klass_type())) {
            In the normal case, we have a perfect match - so we rely on profiling and do speculative String::NonNull*. But in the flag case, we see Object* is not subtype of String*, and continue. So we continue on, and find that profiling has determined never_see_null = true, so we set an uncommon_trap for the null_check.
            Somehow, the speculative profiling case does not lead to a trap - not sure why yet.
            Of course in the test we eventually do feed in Null - in the regular case there is no trap, in the flag case we trap and deopt, breaking the test assumption.
            At any rate, this really looks like a test bug - the flag can change the decisions that have an impact on the asserts of the test. I will disable the flag.

        compiler/ciReplay/TestInliningProtectionDomain.java
            java.lang.RuntimeException: assertTrue: expected true, was false
            this is from an assertTrue.
            Asserts.assertTrue(inlineesReplay.get(4).compare("compiler.ciReplay.InliningBar", "bar2", inlineesReplay.get(4).isForcedByReplay()));
            Turns out isForcedByReplay() returns false because the "reason" is expected to be "force inline by ciReplay", but we get a reason "force (incremental) inline by ciReplay". seems expected. Test Bug. Replace assert with:
            Asserts.assertTrue(inlineesReplay.get(4).compare("compiler.ciReplay.InliningBar", "bar2", inlineesReplay.get(4).isForcedByReplay() || inlineesReplay.get(4).isForcedIncrementalInlineByReplay()));


        First found in JDK-8291775
        Now rediscovered during JDK-8256540

        Attachments

          Issue Links

            Activity

              People

                epeter Emanuel Peter
                epeter Emanuel Peter
                Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                  Created:
                  Updated:
                  Resolved: