CreateEx at the start of a block

[Vladimir Kozlov]

Tom,

This problem and 6776584 bug happened with nsk.stress test
nsk/stress/jck60/jck60017

I tried to reproduce it with CTW rt.jar and got an other problem:

Current function is PhaseChaitin::verify_base_ptrs
   306                 assert(check->is_Mach() && check->as_Mach()->ideal_Opcode() == Op_AddP,"Bad 
derived pointer")
[t at 8 l at 8]: print check->dump()
  27	loadP	===  11  13  12  [[ 2130  2776  2297  713 ]] byte[int:>=0]:exact * !jvms: 
ByteBuffer::array @ bci:1 IDLJavaSerializationInputStream::printBuffer @ bci:4

I have to comment the phi check: /* && check->_idx >= _oldphi */
since the graph has old phis which merge lea instructions.

_oldphi = 2206U

  27	loadP	===  11  13  12  [[ 2130  2776  2297  713 ]] byte[int:>=0]:exact * !jvms: 
ByteBuffer::array @ bci:1 IDLJavaSerializationInputStream::printBuffer @ bci:4
  2297	MachSpillCopy	=== _  27  [[ 353  345  339  316  308  296  287  279  271  263  236  230  225 
202  190  181  176  168  160  133  127  122  98  90  2230  1619  1459  1348  1341  1333  2494  2705 ]]
  2230	MachSpillCopy	=== _  2297  [[ 966 ]]
  967	leaPIdxOff	=== _  2631  2681  2682  [[ 2683 ]] #16
  2683	MachSpillCopy	=== _  967  [[ 966 ]]
  966	Phi	===  80  2230  2683  [[ 2508 ]]  #byte[int:>=0]:NotNull:exact+any *
  2508	Phi	===  79  966  2508  [[ 2509  71  935  923  914  909  901  893  884  872  864  858  850 
842  834  2508 ]]  #byte[int:>=0]:NotNull:exact+any *

As I understand it could be also a problem.
Note: I tested without EA.

Thanks,
Vladimir

Tom Rodriguez wrote:
> It certainly must be at the beginning of the block during register 
> allocation, otherwise I don't think the interference graph will be 
> handled correctly.  The CreateEx represents the incoming exception in a 
> fixed register and it needs to interfere with every value coming into 
> the exception handler.  If a MachSpillCopy is before it then a value 
> could be live into the exception point in the exception oop register, 
> where it would be blown away.  So I think it's a pretty hard rule.  When 
> are you hitting this assert?
> 
> tom
> 
> On Dec 4, 2008, at 12:15 PM, Vladimir Kozlov wrote:
> 
>> How strict that CreateEx should be at the start of a block?
>>
>> History:
>> I am investigating 6776584: EA on sparcV9 Error: before block local 
>> scheduling
>> I also reproduced the problem with 32-bits VM on x86:
>>
>>  two separate float values coming into the block
>>  use the same register:
>>
>> [t at 8 l at 8]: print n->dump(1)
>> 2409    Phi    ===  348  2822  2388  [[ 725  2475  2824  2823  2475  
>> 725  756  756  756  756  756  756 ]]  #float
>> 725    cmpX_cc    === _  2409  2409  [[ 726  724 ]]
>>
>> [t at 8 l at 8]:  print _reg_node[reg_lo]->dump(1)
>> 2388    MachSpillCopy    === _  2279  [[ 2409  2411 ]]
>> 2411    MoveF2I_reg_reg_sse    === _  2388  [[ 724 ]]  !orig=[727]
>>
>> [t at 8 l at 8]: print OptoReg::dump(reg_lo)
>> XMM1a
>>
>> The problem is reported by Scheduling::verify_good_schedule().
>> So I am trying to find when it happened. During RA some verification
>> is done under VerifyOpto. But currently it is broken - it reports too
>> many problems (we miss ton of places where a node is subsumed
>> but it uses were not put on igvn working list, an other bug too fix,
>> I spent day yesterday but still hitting problem so I drop it for now).
>>
>> I added new flag VerifyRegisterAllocator to check only RA.
>> And it immediately gives this:
>>
>> Current function is PhaseCFG::verify
>>  894                   "CreateEx must be first instruction in block" );
>>
>> [t at 8 l at 8]: print b->dump()
>> B23: #    B35 B24 B34 <- N269  Freq: 5.49441e-06
>> 286    Region    ===  286  117  [[ 286  114  119 ]]
>> 399    MachSpillCopy    === _  91  [[ 114 ]]   
>> Oop:java/lang/String:NotNull:exact *
>> 398    MachSpillCopy    === _  95  [[ 114  443 ]]
>> 397    MachSpillCopy    === _  353  [[ 114  442 ]]
>> 396    MachSpillCopy    === _  352  [[ 114  441 ]]   
>> Oop:java/util/Locale:exact *
>> 395    MachSpillCopy    === _  380  [[ 114  440 ]]   
>> Oop:java/util/ResourceBundle$Control *
>> 119    CreateException    ===  286  100  [[ 393 ]] 
>> java/lang/Throwable:NotNull * Oop:java/lang/Throwable:NotNull * !jvms: 
>> ResourceBundle::loadBundle @ bci:83
>> ...
>>
>> Is this a problem?
>>
>> Thanks,
>> Vladimir
>>
>>
>