[13] RFR(S): 8224658: Unsafe access C2 compile fails with assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr: adr_type = NULL

[Vladimir Ivanov]

> http://cr.openjdk.java.net/~thartmann/8224658/webrev.01/

Looks good.

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 [1] 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 
com.sun.tools.javac.tree.Pretty.visitLiteral(Lcom/sun/tools/javac/tree/JCTree$JCLiteral;)V 
jdk.compiler at 13-ea (282 bytes) @ 0x00007f55b4df37d6 
[0x00007f55b4df07a0+0x0000000000003036]

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 
when crashing.

Best regards,
Vladimir Ivanov

[1] https://bugs.openjdk.java.net/browse/JDK-8219902

> 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.
>>
>> Thanks,
>> Tobias
>>