JDK-8025220 : Compilation policy fails with assert(!m->was_never_executed()) failed: don't reset to 0 -- could be mistaken for never-executed
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: hs25,8,9,10,11,12,13,15,16
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2013-09-23
  • Updated: 2021-01-29
  • Resolved: 2021-01-29
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 17
17Resolved
Related Reports
Duplicate :  
JDK-8206938 - Compilation policy fails with assert(!m->was_never_executed()) failed: don't reset to 0 -- could be mistaken for never-executed
Duplicate :  
JDK-8251462 - Simplify compilation policy
Duplicate :  
JDK-8159808 - Assertion failure in runtime/compilationPolicy.cpp: assert(!m->was_never_executed()) failed
Duplicate :  
JDK-8246735 - assert(!m->was_never_executed()) failed: don't reset to 0 -- could be mistaken for never-executed #
Description
java/util/stream/test/org/openjdk/tests/java/util/stream/SortedOpTest.java

Fails with:
assert(!m->was_never_executed()) failed: don't reset to 0 -- could be mistaken for never-executed

#  Internal Error (c:/jprt/T/P1/005104.tkrodrig/s/hotspot/src/share/vm/runtime/compilationPolicy.cpp:280), pid=32084, tid=28832
#  assert(!m->was_never_executed()) failed: don't reset to 0 -- could be mistaken for never-executed
#
# JRE version: Java(TM) SE Runtime Environment (9.0) (fastdebug build 9-internal+0-2016-05-12-005104.tkrodrig.hs-comp)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 9-internal+0-2016-05-12-005104.tkrodrig.hs-comp, compiled mode, g1 gc, windows-amd64)
Comments
No, that's not realistic. Once the counter is greater than the limit the interpreter would do the callback (in another thread) and the counter value would be set to CompileThreshold/2. That update can be missed of course, but if it is there's going to another callback the next time.
30-04-2019
I haven't really looked at this in detail but shouldn't it be possible that while one thread is right before executing the code/assert in NonTieredCompPolicy::reset_counter_for_invocation_event(), another thread continues incrementing the counter until it overflows to zero?
30-04-2019
Hm, does this occur only on windows?
29-04-2019
Alright, taking another look at this one: So far.. The assert is triggered after we did set_carry() to the problematic invocation counter. We know that: 1. The MethodCounters exist (so that's not an OOM situation of any kind). 2. We obviously missed the last write to the counters (because set_carry() would set the counter to at least 1). Missing the write is normal and benign, however the operations of the counters are such that once it goes > 1 it stays >1, no matter how many writes are missed. So, in this case a situation must occur that we do write a 0 to the counter. I still fail to see though how that could possibly happen.
29-04-2019
This showed up again (see JDK-8206938 and all the linked instances). Therefore targeting for JDK 13.
04-01-2019
9-defer-request: The issue is benign in nature: observing the 0 count will not cause any crashes in product. Also, the issue is only with the non-tiered compilation policy, so it will not occur with default flags.
16-08-2016
RULE "java/util/stream/test/org/openjdk/tests/java/util/stream/SliceOpTest.java" Crash Internal Error ...compilationPolicy.cpp...assert(!m->was_never_executed()) failed: don't reset to ... -- could be mistaken for never-executed RULE "java/util/stream/test/org/openjdk/tests/java/util/stream/WhileOpTest.java" Crash Internal Error ...compilationPolicy.cpp...assert(!m->was_never_executed()) failed: don't reset to ... -- could be mistaken for never-executed
22-06-2016
Any possibility of a race with Method compilation in another thread?
16-06-2016
I really fail to see any possible scenario (except of a C compiler bug) for this to happen.
15-06-2016
ILW = assert; intermittent; none = MLH = P4
15-06-2016
ILW = assert; 2 failures in whole history ;none = MLH => P4
06-06-2016
Having trouble reproducing it. And after considering all the possible races (considering the wait-free nature of the counters) I cannot really imagine a case in which at the point of the assert the counter is 0 _and_ the carry is not set. Will poke around some more.
25-09-2013