RFR: 8250825: C2 crashes with assert(field != __null) failed: missing field

[Vladimir Kozlov]

Good.

thanks,
Vladimir K

On 7/30/20 10:06 PM, jiefu(傅杰) wrote:
> Hi Vladimir K,
> 
> Thanks for your review.
> 
> The test had been extended here:
>    - http://cr.openjdk.java.net/~jiefu/8250825/webrev.01/
> 
> Before the patch:
>    The unsafe access (put/get) to static field will crash.
>    The unsafe access (put/get) to instance field is fine.
> 
> After the patch:
>    All is ok.
> 
> Thanks a lot.
> Best regards,
> Jie
> 
> On 2020/7/31, 2:24 AM, "hotspot-compiler-dev on behalf of Vladimir Kozlov" <hotspot-compiler-dev-retn at openjdk.java.net on behalf of vladimir.kozlov at oracle.com> wrote:
> 
>      Hi Jie
>      
>      Nodes generated by make_unsafe_address() are correct. The issue is that Unsafe API allows to genereate unaligned (to
>      fields) offset with arbitrary type. As result C2 type system can't find corresponding field.
>      
>      Did you tried to do unaligned unsafe access to instance fields?
>      Also try to unsafe set value (Store node). There is code in C2 which checks for narrow stores. Would be interesting how
>      it behave in unsafe case.
>      
>      Please, extend your test.
>      
>      Otherwise fix is good.
>      
>      Thanks,
>      Vladimir K
>      
>      On 7/30/20 6:09 AM, jiefu(傅杰) wrote:
>      > Hi all,
>      >
>      > JBS:    https://bugs.openjdk.java.net/browse/JDK-8250825
>      > Webrev: http://cr.openjdk.java.net/~jiefu/8250825/webrev.00/
>      >
>      > When C2 tries to inline an unsafe-access method, it may generate the following pattern in make_unsafe_address:
>      >        ConP  ConL
>      >           \  |
>      >            \ |
>      >            AddP
>      > Current implementation of TypeOopPtr::TypeOopPtr(...) failed to recognize it as an unsafe operation, which leads to the crash.
>      >
>      > Testing:
>      >    - tier1-3 on Linux/x64
>      >
>      > Could you please review it and give me some advice?
>      >
>      > Thanks a lot.
>      > Best regards,
>      > Jie
>      >
>      
>      
>