[9] RFR (XS): 8155635: C2: assert(flat != TypePtr::BOTTOM) failed: cannot alias-analyze an untyped ptr

Vladimir Kozlov vladimir.kozlov at oracle.com
Fri Apr 29 23:39:13 UTC 2016


I am not comfortable with this fix. You may replace in(Base) != NULL with TOP.
Also it should not be RAW pointer (TOP as Base) if it is created by graph transformation from normal oop pointer.
I think we should track which pointers are really RAW when creating them.

Can you explain why we have such graph shape where we access memory after a merge point and on one merged path has NULL 
as pointer to object. There should be NULL check after merge before memory access in such case.

Thanks,
Vladimir K

On 4/29/16 4:11 PM, Vladimir Ivanov wrote:
> http://cr.openjdk.java.net/~vlivanov/8155635/webrev.00/
> https://bugs.openjdk.java.net/browse/JDK-8155635
>
> SplitIf transformation can produce untyped pointers when slitting AddP nodes for unsafe accesses through a Phi which
> merges non-null & null values:
>     AddP ... (Phi (ConP #NULL) (CheckCastPP Oop:...:NotNull))
>
> Proposed fix is to enable oop pointer to raw pointer conversion for absolute addresses.
>
> I also experimented with blocking SplitIf transformation is such cases, but the transformation seems viable and
> considerably simplifies the graph: X-shaped control flow is untangled by eliminating redundant and the transformation
> sharpens types on both branches.
>
> I checked specifically how Phi merges raw & oop pointers after the split and it works fine.
>
> Testing: failing test, JPRT, RBT (hs-tier0-comp.js).
>
> Thanks!
>
> Best regards,
> Vladimir Ivanov
>
> PS: though AddP (Phi #NULL #NotNull) shape is common, I wasn't able to write a simplified test case which triggers
> SplitIf transformation.


More information about the hotspot-compiler-dev mailing list