Problem with testN_mem_reg0 in register allocation.

[Vladimir Kozlov]

Goetz, Martin

I would speculate it is scheduled very early by GCM because of memory 
access anti-dependency. Somewhere there is a store or other changes to 
this memory slice. Yes, matcher should not allow such matching. I am not 
sure we have an anti-dependency check when we match (need to look). The 
method which should do that is Matcher::find_shared().

The easiest fix would be in place where we try to spill flag do bailout 
with recompilation without subsuming loads:

     if (C->subsume_loads() == true && !C->failing()) {
       // Retry with subsume_loads == false
       // If this is the first failure, the sentinel string will "stick"
       // to the Compile object, and the C2Compiler will see it and retry.
       C->record_failure(C2Compiler::retry_no_subsuming_loads());

Regards,
Vladimir

On 8/19/13 8:04 AM, Lindenmaier, Goetz wrote:
> Hi,
>
> we are currently analyzing a bug in our jdk7 VM, which is based on
> HS23.  It happens on linux x86_64.
>
> Register allocation tries to spill a RefFlags register, and, as to
> expect, fails on this leading to a SIGSEGV.
>
> I suspect this is a strange interdependency between gcm and
> register allocation
>
> Gcm produces something as the following pattern (I simplified
> to get the essentials).
>
>            Block 35
>              Call
>              209 testN_mem_reg0
>              Catch
>         /              \
>        /                \
>      |/_                _\|
> Block 36             Block 146
>    ...                 ...
>                        159 testP_reg
>                        158 jmpCon(212)
>       \                   /
>        \                 /
>        _\|             |/_
>          Block 39
>            ...
>         /              \
>        /                \
>      |/_                _\|
> Block 140              ...
>    208 jmpCon(209)
>
> Then call_catch_cleanup() repairs the position of 209.
> It adds 1088, 1089 and 1090.
>
>            Block 35
>              Call
>              Catch
>         /              \
>        /                \
>      |/_                _\|
> Block 36               Block 146
>    1089 testN_mem_reg0    1088 testN_mem_reg0
>    ...                    ...
>                           159 testP_reg
>                           158 jmpCon(212)
>       \                   /
>        \                 /
>        _\|             |/_
>          Block 39
>            1090 Phi(1089, 1088)
>            ...
>         /              \
>        /                \
>      |/_                _\|
> Block 140              ...
>    208 jmpCon(1090)
>
> Register allocation now wants to spill the register of 1088.
> This is necessary as 159 needs the flag register.
> Have you seen such a problem before?
>
> We could envision that one the following 3 behaviors is expected and
> should get fixed:
>
> 1. gcm should place node 209 in Block 140.
> 2. Register allocation should be able to properly rematerialize the
> testN_mem_reg0 node (which does allow rematerialization).
>     This would require that it recognizes that the Phi merges twice the
> same value.
> 3. The matcher should not match this node (which matches on a Load and
> Cmp)?
>
> Best reagrds,
> Martin & Goetz.
>