JDK-8193323 : Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-12-11
  • Updated: 2019-09-13
  • Resolved: 2017-12-14
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 10 JDK 11
10 b37Fixed 11Fixed
Related Reports
Relates :  
JDK-8191688 - Assert failed in > 200 tests: failed dependencies, but counter didn't change
Relates :  
JDK-8191052 - [Graal] java/lang/invoke/CallSiteTest.java intermittently fails with "Failed dependency of type call_site_target_value" when running with Graal as JIT
Description
Hotspot crashes with 
#  Internal Error (src/hotspot/share/code/dependencies.cpp:686)
#  assert(counter_changed) failed: failed dependencies, but counter didn't change

when -XX:+UseJVMCICompiler flag is used.
Comments
JVMCI can encounter redefined "old" methods in CompileBroker::invoke_compiler_on_method(), even before we start to compile, and through inlinining it may be possible to encounter even more already-redefined methods, with no guarantee that the SystemDictionary count will change, so it seems like JVMCI needs a way to tell Graal not to compile or inline these methods, like C1 and C2.
13-12-2017
I see now that VM_RedefineClasses::doit() does call SystemDictionary::notice_modification(), which should be under a safepoint. I guess I need to study what race JDK-6328518 was trying to solve and see if JVMCI has it.
12-12-2017
The counter_changed flag is there so we don't revalidate dependencies in product mode when the system dictionary didn't change. So the assert is confirming that the check is really redundant. I don't see how the not compilable solution deals with races though. The ciMethod could become redefined after the ciMethod instance has been created so you'd still produce a method with the old bytecodes. I think you still need to check the evol_method deps before code installation. Bumping the counter would properly trigger rechecking all settings but it think adding evol_method to non_klass_types would also do it and it would restore the way JVMCI worked before.
12-12-2017
C1/C2 make the method temporarily non-compilable/non-inlinable. But maybe there's a better way. I'm not sure what the assertion is protecting us against. Should class redefinition count as a dictionary change and bump the counter, or would that mask a deeper problem?
12-12-2017
[~never] I think this is related to the JDK-8191052 changes. Before that, JVMCI would return an error but not assert. I wonder if JVMCI needs the JDK-6328518 workaround that C1/C2 use.
12-12-2017
I think it's because we used to include evol_method in the section before the counter_changed part of the logic. I had assumed that is_klass_type included that dep but it doesn't. How do C1/C2 handle evol_method properly if the counter hasn't changed?
12-12-2017
ILW = Assert fails during compilation due to unexpected dependencies change, 4 tests, no workaround = MMH = P3
12-12-2017
All failing tests are related to hotswap. The fix for JDK-8191688 changed the hotswap related ciMethod code http://hg.openjdk.java.net/jdk/jdk/rev/6199dfaf72da#l2.15 [~dlong], could you please have a look?
12-12-2017