JDK-8205574 : Loop predication "assert(f <= 1 && f >= 0) failed Incorrect frequency"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows
  • Submitted: 2018-06-24
  • Updated: 2022-02-26
  • Resolved: 2019-01-17
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 JDK 12
11.0.4Fixed 12 b20Fixed
Related Reports
Relates :  
SKARA-964 - Should only consider Fixed bugs for hgupdate-sync
Relates :  
JDK-8268184 - java/lang/invoke/ArrayLengthTest.java fails "assert(lrg._area >= 0.0) failed: negative spill area"
Relates :  
JDK-8203197 - C2: consider all paths in loop body for loop predication
Description
jvm!VMError::report_and_die+0x81 [d:\dev\jdk\jdk\open\src\hotspot\share\utilities\vmerror.cpp @ 1267]
jvm!report_vm_error+0x89 [d:\dev\jdk\jdk\open\src\hotspot\share\utilities\debug.cpp @ 232]
jvm!PathFrequency::to+0x92b [d:\dev\jdk\jdk\open\src\hotspot\share\opto\looppredicate.cpp @ 950]
jvm!PhaseIdealLoop::loop_predication_impl+0x6b9 [d:\dev\jdk\jdk\open\src\hotspot\share\opto\looppredicate.cpp @ 1379]
jvm!IdealLoopTree::loop_predication+0x7c [d:\dev\jdk\jdk\open\src\hotspot\share\opto\looppredicate.cpp @ 1425]
jvm!IdealLoopTree::loop_predication+0xb3 [d:\dev\jdk\jdk\open\src\hotspot\share\opto\looppredicate.cpp @ 1429]
jvm!PhaseIdealLoop::build_and_optimize+0xf46 [d:\dev\jdk\jdk\open\src\hotspot\share\opto\loopnode.cpp @ 2918]
jvm!PhaseIdealLoop::PhaseIdealLoop+0xaf [d:\dev\jdk\jdk\open\src\hotspot\share\opto\loopnode.hpp @ 943]
jvm!Compile::Optimize+0x98e [d:\dev\jdk\jdk\open\src\hotspot\share\opto\compile.cpp @ 2292]
jvm!Compile::Compile+0x12e2 [d:\dev\jdk\jdk\open\src\hotspot\share\opto\compile.cpp @ 869]
jvm!C2Compiler::compile_method+0x140 [d:\dev\jdk\jdk\open\src\hotspot\share\opto\c2compiler.cpp @ 112]
jvm!CompileBroker::invoke_compiler_on_method+0x6a1 [d:\dev\jdk\jdk\open\src\hotspot\share\compiler\compilebroker.cpp @ 2107]
jvm!CompileBroker::compiler_thread_loop+0x325 [d:\dev\jdk\jdk\open\src\hotspot\share\compiler\compilebroker.cpp @ 1805]
jvm!compiler_thread_entry+0x6c [d:\dev\jdk\jdk\open\src\hotspot\share\runtime\thread.cpp @ 3259]
jvm!JavaThread::thread_main_inner+0x14f [d:\dev\jdk\jdk\open\src\hotspot\share\runtime\thread.cpp @ 1736]
jvm!JavaThread::run+0x1a1 [d:\dev\jdk\jdk\open\src\hotspot\share\runtime\thread.cpp @ 1718]
jvm!thread_native_entry+0x157 [d:\dev\jdk\jdk\open\src\hotspot\os\windows\os_windows.cpp @ 457]
msvcr120!_callthreadstartex+0x17 [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 376]
msvcr120!_threadstartex+0x102 [f:\dd\vctools\crt\crtw32\startup\threadex.c @ 354]
KERNEL32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

Asserts locally during Kitchensink run.

// some context

jvm!PathFrequency::to()
 ...
 float prev_f = _freqs_stack.pop();
 float new_f = f;
 f = new_f + prev_f;
 assert(f <= 1 && f >= 0, "Incorrect frequency");
...

new_f = 0.2216838151
prev_f = 0.778316319
i = 3
n = 0x00000258`2e8e03c8
f = 1.000000119
prev = 0x00000258`15143560
this = 0x000000a0`02ff69a0
n = 0x00000258`1d03cb38
c = 0x00000258`15143560
loop = 0x00000258`21f57690

Method: com/sun/org/apache/xml/internal/serializer/ToStream.outputCharacters()

.mdmp file saved locally.
Comments
Fix Request We see this assertion once in a while in our nightly tests on windows. Thus I would like to downport this fix to 11. As this is P3, I propose pushing this to jdk11u-dev. The patch applies cleanly, and will go through our nightly testing tonight.
26-02-2019
Fix was pushed while main bug was targeted to '11'. Reset the main bug to fixed in '12' and copied the hgupdater entries here.
17-01-2019
HG Updates added a comment - 2018-11-12 06:34 URL: http://hg.openjdk.java.net/jdk/jdk/rev/61915e1458bc User: roland Date: 2018-11-12 11:33:04 +0000
17-01-2019
Closing as WNF for now (this is still open because when Roland pushed the fix to JDK 12, the fix version was set to JDK 11 and therefore a backport was created -> JDK-8213738).
11-01-2019
Made fix ver. tbd, as we (self evidently) aren't going to be fixing this in 11 GA ... maybe someone will address for 11 updates.
10-01-2019
reopening as Martin provided a reproducer
26-10-2018
Hi Roland, we have seen this assertion several times when running jck tests with recent jdk11u: api/xsl/conf/numbering/numbering03.html#numbering03 api/xsl/conf/numbering/numbering05.html#numbering05 Attached replay file.
22-10-2018
I'm closing this as not reproducible as it was not seen again. Not that the error that triggers the assert is largely harmless: worst case a predicate will be moved out of loop when it shouldn't have been causing a small performance loss. Correctness is unaffected. To investigate further, a replay file or a reproducer would be needed.
09-07-2018
I'll try relaunching a few test runs to see if we can reproduce it.
26-06-2018
Could you maybe try to reproduce this in your environment and let it continue to run such that these files are created? Unfortunately, we need a reproducer to debug this and the replay compilation file might help.
26-06-2018
Unfortunately, there are no support files available since this was run inside Windbg. The assertion breaked into the debugger from where i could extract some context in addition to saving the .mdmp file. The hs_err and replay_pid creation code did not get a chance to run.
26-06-2018
[~mgronlun], could you please attach the hs_err and replay_pid files (if available)?
26-06-2018
updated ILW = MMM = P3 (based on the above comments changing Impact to M)
25-06-2018
JDK-8203197 has already been promoted in jdk11+19 so the root cause bug has already been promoted. I'm removing the 'promotion_blocker' label.
25-06-2018
That assert fails if: 1) there's a bug in the computation of frequencies for some path in the loop body, or 2) rounding errors accumulate To address 2), PathFrequency::to changes the rounding mode for fp computations. Maybe that's not sufficient. In any case, I can't verify if it's 1) or 2) unless I can reproduce it. Also the assert is largely harmless: worst case, a predicate that's too infrequent is moved out of loop which would cause a performance regression. So I would say not a P2.
25-06-2018
This code was introduced by JDK-8203197. Roland, can you please have a look?
25-06-2018
initial ILW = Assert failure in c2 loop predication; seems rare, reported with local Kitchensink run, no sighting in mach5 tier testing yet; may be disable UseLoopPredicate = HMM = P2
25-06-2018
may be related to JDK-8205515?
25-06-2018