RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL
vladimir.x.ivanov at oracle.com
Fri Jun 7 14:27:25 UTC 2019
There are existing usages of Halt for optimizing unsafe accesses (e.g.,
GraphKit::must_be_not_null), but, as a future enhancement, it would be
nice to provide more information about the root cause of the crash. As
an example, JDK-8219902  which involved Halt execution manifested as:
# SIGILL (0x4) at pc=0x00007f55b4df37d6, pid=15865, tid=15869
# JRE version: OpenJDK Runtime Environment (13.0+9) (build 13-ea+9)
# Java VM: OpenJDK 64-Bit Server VM (13-ea+9, mixed mode, sharing,
tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# J 10152 c2
jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6
Without laborous analysis of generated code, it's impossible to say
whether it's a JVM bug or a problem in user code. I believe JVM can do
better in such situations and print meaningful error message instead
> On 23.05.19 15:21, Tobias Hartmann wrote:
>> Hi Vladimir,
>> thanks for looking at this.
>> On 23.05.19 15:09, Vladimir Ivanov wrote:
>>> The fix should work fine for Unsafe.getXxx(0) case, but what if address turns into 0 later? For
>>> example, I don't see a reason why it can't theoretically happen in presence of post-parse inlining
>>> happening in effectively unreachable code.
>> Yes that's possible and I thought it doesn't matter because we won't hit that assert during IGVN.
>> I've just checked in detail and C2 actually completely removes the unsafe access in that case which
>> is obviously incorrect.
>> I'll come back once I have a fix ready.
More information about the hotspot-compiler-dev