JDK-8201447 : C1 does backedge profiling incorrectly
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2018-04-11
  • Updated: 2018-09-25
  • Resolved: 2018-05-16
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 11
11 b14Fixed
Related Reports
Relates :  
Relates :  
Description
While looking into an issue with a Graal bailout because the OSR entry point appeared to be unreachable I noticed that when C1 profiles if bytecodes it increments the backedge counter on every execution of the if instead of just on the backedge.  For a simple loop like this:

public class dowhile {
    public static void main(String[] args) {
        for (int i = 0; i < 10000000; i++) {
            testDoWhile();
        }
    }
    public static volatile boolean repeatLoop;
    static volatile int sideEffect;

    public static void testDoWhile() {
        do {
            sideEffect++;
        } while (repeatLoop);
    }
}

HotSpot ends up requesting an OSR compile:

<task_queued compile_id='16' compile_kind='osr' method='dowhile testDoWhile ()V' bytes='15' count='224300' backedge_count='163840' iicount='224300' osr_bci='0' level='4' stamp='0.576' comment='tiered' hot_count='163840'/>
Comments
That looks good.
15-05-2018

An easier cmove-based solution: http://cr.openjdk.java.net/~iveresov/8201447/webrev.01/ We actually don't need to supported a separate floating point case because apparently we already disable canonicalizations that can cause unordered to dispatch to the true branch.
15-05-2018

Hm, ok, I guess I'll need to write a 3-operand cmove LIR_Op for FP compares then.
11-05-2018

Writing branching control flow at the LIR level is usually unsafe. It will often work just fine but if linear scan decides it needs to spill in the middle of that control flow then the code will be incorrect. This could be instead done by cmov'ing the required values based on the test. You could increment the backedge counter by 0 in the case where it shouldn't be incremented. I couldn't figure out how to simulate the unordered logic for a cmove though. Making the backedge and taken/not_taken increments into a single LIR_Op would also work.
11-05-2018

Suggested fix: http://cr.openjdk.java.net/~iveresov/8201447/webrev.00/
10-05-2018

initial ILW = wrong backedge count by C1, possible compilation bailouts; with profiling by C1; none = MMH = P3
12-04-2018