JDK-8201821 : [Graal] Various exceptions and crashes running FJP JMH micros
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-04-18
  • Updated: 2023-07-21
  • Resolved: 2023-07-21
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
11Resolved
Related Reports
Duplicate :  
JDK-8202670 - Update Graal
Relates :  
JDK-8198909 - [Graal] compiler/codecache/stress/UnexpectedDeoptimizationTest.java crashed with SIGSEGV
Description
I've seen a variety of crashes and a couple deadlocks running the JMH from the http://hg.openjdk.java.net/code-tools/jmh-jdk-microbenchmarks/ project:

/opt/jdk-11-b9/bin/java -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.compiler=graal -jar target/jmh-jdk-microbenchmarks-1.0-SNAPSHOT.jar   bulk_par_lambda -t 1 -rf json -rff jmh.json -wi 1 -i 1

Doesn't seem to happen with +UseParallelGC.
Trying older builds, problems happen at least as early as 11-b3.
Comments
Fixed by JDK-8202670.
30-05-2018
Should be fixed by https://github.com/oracle/graal/commit/39883a015c38645a9fe2e31b34d1014f6712fab2
30-05-2018
For the record I have reproduced the crash in java_lang_Class::as_Klass with a fastdebug build including this fix so I think it's confirmed that it's a separate issue.
29-05-2018
-XX:+VerifyBeforeGC reports a missing rem set entry for an array of ForkJoinTasks. I can see that there is an array of the proper type which is updated using compareAndSwapObject, so I started looking at our logic around barriers and CAS. One thing I notice is that we might sometimes use an imprecise barrier for a CAS and the logic for selecting between them isn't safe. It's just checking that the declared type isn't an array when it should be checking that the declared type isn't assignable from Object[]. I don't actually see that path being exercised in the failing program but I think it's clearly wrong. I'll continue to investigate if that's the actual source of this problem.
17-05-2018
This problem happened in aurora-perf testing where Volano hung for 24 hours clogging up the overnight workflow. So this is pretty important to get fixed for performance testing.
20-04-2018
ILW = Crashes using Graal; only with Graal for JMH runs; disable Graal! = HMM = P2
20-04-2018