JDK-8056058 : C2 assert: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr when running SPECjbb2013
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 8u40,9
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2014-08-26
  • 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 9
9Resolved
Related Reports
Duplicate :  
Relates :  
Description
When running SPECjbb2013 on a fastdebug build I get the following crash:

#
#  Internal Error (/localhome/hg/hs-gc-clean/src/share/vm/opto/compile.cpp:1662), pid=12975, tid=139818001143552
#  assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr
#
# JRE version: Java(TM) SE Runtime Environment (8.0_20-b22) (build 1.8.0_20-ea-fastdebug-b22)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.9.0-fastdebug-internal-hs-gc-clean mixed mode linux-amd64 compressed oops)
# Core dump written. Default location: /localhome/mgerdin/tests/rw/benchmarks/specjbb2013/core or core.12975
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.sun.com/bugreport/crash.jsp
#

---------------  T H R E A D  ---------------

Current thread (0x00007f2b05851000):  JavaThread "C2 CompilerThread1" daemon [_thread_in_native, id=13147, stack(0x00007f29ea3a9000,0x00007f29ea4aa000)]

Stack: [0x00007f29ea3a9000,0x00007f29ea4aa000],  sp=0x00007f29ea4a3c20,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xff8666]  VMError::report(outputStream*)+0x1124
V  [libjvm.so+0xff9c95]  VMError::report_and_die()+0x411
V  [libjvm.so+0x7b3188]  report_vm_error(char const*, int, char const*, char const*)+0xb4
V  [libjvm.so+0x7216bf]  Compile::find_alias_type(TypePtr const*, bool, ciField*)+0x15f
V  [libjvm.so+0x3b7376]  Compile::alias_type(TypePtr const*, ciField*)+0x40
V  [libjvm.so+0x6445e6]  Compile::get_alias_index(TypePtr const*)+0x38
V  [libjvm.so+0x72532a]  Compile::final_graph_reshaping_impl(Node*, Final_Reshape_Counts&)+0x20e
V  [libjvm.so+0x726ea3]  Compile::final_graph_reshaping_walk(Node_Stack&, Node*, Final_Reshape_Counts&)+0x237
V  [libjvm.so+0x7273b2]  Compile::final_graph_reshaping()+0x184
V  [libjvm.so+0x723f3c]  Compile::Optimize()+0xd86
V  [libjvm.so+0x71d650]  Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool)+0x11bc
V  [libjvm.so+0x616c04]  C2Compiler::compile_method(ciEnv*, ciMethod*, int)+0x118
V  [libjvm.so+0x73ab72]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x4e0
V  [libjvm.so+0x73a09a]  CompileBroker::compiler_thread_loop()+0x3c2
V  [libjvm.so+0xf848f7]  compiler_thread_entry(JavaThread*, Thread*)+0x66
V  [libjvm.so+0xf7f0b1]  JavaThread::thread_main_inner()+0x183
V  [libjvm.so+0xf7ef0b]  JavaThread::run()+0x189
V  [libjvm.so+0xdbf103]  java_start(Thread*)+0x1ca
C  [libpthread.so.0+0x8182]  start_thread+0xc2


Current CompileTask:
C2:4472860 12046 %     4       java.util.concurrent.ForkJoinPool$WorkQueue::growArray @ 83 (174 bytes)

It seems to regularly crash when osr-compiling that particular method at bci 83.

I=M, assert in fastdebug but product seems to run fine
L=H, assert fires every time the benchmark is run
W=H, no known workaround
=>P2
Comments
Duplicates JDK-8155635.
16-08-2016

[~neliasso] looks like I found the root cause (JDK-8155635). I'm working on the fix, so will take care of the bug.
29-04-2016

P4 -> deferring out of 8u60 keeping on 9.
29-05-2015

retriage: ILW=Assert in debug - no product impact, 100% Reproducible on benchmark on non-product build, none=MLM=P4
29-05-2015

This bug is caused by an assert on that the type should not be getting worse during the compilation. Look like a sun.misc.unsafe.compareandswap side effect. MergeMem from a SCMemProj with type:bot and a memstate with type: top. Looks correct to me. Assert triggers in debug builds, runs fine in product. 100% reproducible.
02-12-2014

ILW=Assert in compilation, reproducible, none=MMH=P3
26-11-2014

Looks like https://bugs.openjdk.java.net/browse/JDK-8041482 too. But should be fixed since this summer. So I suggest keep this open and investigate futher.
25-11-2014

Looks like JDK-8060024.
24-11-2014

In my case the crash reproduced with CMS.
19-11-2014

It seems to not reproduce without UseG1GC
26-08-2014

As can be seen in the hs_err I'm running a 9-based JVM with an 8u20 JDK. But the crash reproduces with a 9-based JDK built from jdk9/hs-comp as well.
26-08-2014