JDK-8218926 : [libgraal] Uncaught exception at jvmciRuntime.cpp:1491 java.lang.StackOverflowError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: repo-metropolis
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2019-02-13
  • Updated: 2019-03-19
  • Resolved: 2019-03-19
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.
Other
repo-metropolisResolved
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
During testing of JDK-8218847 changes I found few failures. This is one of them:

With " -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal" flags
Uncaught exception at open/src/hotspot/share/jvmci/jvmciRuntime.cpp:1491 
java.lang.StackOverflowError

test/hotspot/jtreg/compiler/uncommontrap/TestStackBangRbp.java 

Comments
GR-14278 fix was included in JDK-8219995 changes.
19-03-2019

Metropolis repo will be testing Graal in both mode: as Java code and as libgraal. CompileGraalWithC1Only may still make sense. But I don't see it is used anywhere in HotSpot tests task definitions or tests. Base on code in HotSpotGraalCompilerFactory.java the flag's default value is 'true' - it is used by default.
25-02-2019

adjustCompilationLevel() is currently only used to support the Graal options CompileGraalWithC1Only and GraalCompileOnly. For Metropolis with libgraal, CompileGraalWithC1Only doesn't make sense to me, and it looks like the GraalCompileOnly part is already taken care of: https://java.se.oracle.com/source/xref/jdk-jdk/open/src/jdk.internal.vm.compiler/share/classes/org.graalvm.compiler.hotspot/src/org/graalvm/compiler/hotspot/CompilationTask.java#323 So the fix for Metropolis should be simpler than the fix for JDK13. Just remove the call to adjust_comp_level().
25-02-2019

Yes we'll be deleting the code so the problem will go away.
22-02-2019

That it was Tom told. So yes, it could be duplicate but please verify.
21-02-2019

This should go away if we fix JDK-8219403, right?
21-02-2019

Failed tests passed with this patch.
15-02-2019

Thanks! I will tests the patch.
14-02-2019

I think the difference is that the problem happens with the old JVMCI but we didn't treat it as a hard error. From the regular JDK from. ----------System.out:(645/50467)---------- CompileCommand: dontinline compiler/uncommontrap/TestStackBangRbp.m1 CompileCommand: exclude compiler/uncommontrap/TestStackBangRbp.m2 Uncaught exception while adjusting compilation level: java.lang.StackOverflowError java.lang.StackOverflowError at org.graalvm.compiler.hotspot.HotSpotGraalCompilerFactory.adjustCompilationLevel(jdk.internal.vm.compiler@13-internal/Ho tSpotGraalCompilerFactory.java:166) at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel(jdk.internal.vm.ci@13-internal/HotSpotJVMCIRuntime.java:50 3) at java.lang.String.isLatin1(java.base@13-internal/String.java:3465) I think the exception handling in JVMCIRuntime::adjust_comp_level_inner has a few problems. The CHECK_RETURN macro is still assuming it's interacting with HotSpot and should be rewritten to operate on JVMCIENV but it also needs the special ThreadDeath handling for HotSpot case. Something like the attached fix.patch.
13-02-2019