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
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-11-09
  • Updated: 2019-09-13
  • Resolved: 2017-12-04
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 b36Fixed 11Fixed
Related Reports
Relates :  
JDK-8193323 - Crash in "failed dependencies, but counter didn't change" with enabled UseJVMCICompiler
Relates :  
JDK-8191930 - [Graal] emits unparseable XML into compile log
Relates :  
JDK-8206931 - Misleading "COMPILE SKIPPED: invalid non-klass dependency" compile log
Description
java/lang/invoke/CallSiteTest.java intermittently fails with 

hread[JVMCI CompilerThread7,9,system]: Compilation of test.java.lang.invoke.CallSiteTest.runVolatileCallSite() failed: java.lang.AssertionError: dependencies invalid Code installation failed: dependencies invalid
Failed dependency of type call_site_target_value
  object  = a 'java/lang/invoke/VolatileCallSite'{0x00000000e6abe728}
  object  = a 'java/lang/invoke/DirectMethodHandle'{0x00000000e6abf240}
  witness = java.lang.invoke.VolatileCallSite

        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotCodeCacheProvider.installCode(HotSpotCodeCacheProvider.java:129)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.core.target.Backend.createInstalledCode(Backend.java:212)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.CompilationTask.installMethod(CompilationTask.java:357)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.CompilationTask.access$500(CompilationTask.java:63)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.CompilationTask$HotSpotCompilationWrapper.performCompilation(CompilationTask.java:179)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.CompilationTask$HotSpotCompilationWrapper.performCompilation(CompilationTask.java:94)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.core.CompilationWrapper.run(CompilationWrapper.java:165)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.CompilationTask.runCompilation(CompilationTask.java:317)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.HotSpotGraalCompiler.compileMethod(HotSpotGraalCompiler.java:142)
        at jdk.internal.vm.compiler@10-internal/org.graalvm.compiler.hotspot.HotSpotGraalCompiler.compileMethod(HotSpotGraalCompiler.java:108)
        at jdk.internal.vm.ci/jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.compileMethod(HotSpotJVMCIRuntime.java:437)
To disable compilation failure notifications, set CompilationFailureAction to Silent (e.g., -Dgraal.CompilationFailureAction=Silent).
To print a message for a compilation failure without retrying the compilation, set CompilationFailureAction to Print (e.g., -Dgraal.CompilationFailureAction=Print).
Retrying compilation of test.java.lang.invoke.CallSiteTest.runVolatileCallSite()

Exiting VM after retry compilation of test.java.lang.invoke.CallSiteTest.runVolatileCallSite()

when running with Graal as JIT compiler.
Comments
Thanks Tom.
14-11-2017
This was a missed forward port from graal-jvmci-8 to 10. I've taken the opportunity to refactor the logic as suggested by Doug so that ciEnv and JVMCIEnv can share the logic.
14-11-2017
I opened JDK-8191098 to do the factoring out as a separate issue.
11-11-2017
This is a good opportunity to consolidate the duplicated logic between jvmciEnv and ciEnv by introducing a common subclass (e.g. compEnv). A quick glance indicates that other non-trivial methods such as get_klass_by_index_impl and get_method_by_index_impl contain a lot of shared logic.
10-11-2017
This failure is due to the fact that JVMCI does not expect call site invalidation during compilation which is obviously a false assumption. JVMCI needs to treat this as normal instead of an invalid dependency. That is, JVMCIEnv::check_for_system_dictionary_modification [1] needs to be more like ciEnv::validate_compile_task_dependencies [2]. [1] http://hg.openjdk.java.net/jdk/hs/file/7437dc810834/src/hotspot/share/jvmci/jvmciEnv.cpp#l411 [2] http://hg.openjdk.java.net/jdk/hs/file/7437dc810834/src/hotspot/share/ci/ciEnv.cpp#l897
10-11-2017
ILW = Failed dependency of type call_site_target_value for CallSiteTest.java; one test failure, only with graal as jit; disable graal = HLM = P3
10-11-2017
Steps to reproduce: jtreg -vt -k:\!ignore -jdk:HS10_fastdebug -javaoptions:"-ea -esa -Xmx512m -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal" -dir:test/jdk java/lang/invoke/CallSiteTest.java The failure is intermittent but I can reproduce it every 3rd time.
09-11-2017