ciTypeFlow, osrs and jsr/ret

[Tom Rodriguez]

I think this question is targeted at John.  I'm looking into a crash  
with ciTypeFlow where irreducible loops are being caused by exception  
edges plus a lot of jsr/rets that cause cloning which greatly  
increases the graph complexity, going from 50 or so blocks to almost  
3000.  I think I understand the crash itself which is caused by the  
check for irreducibility but if I fix that I still get a failure when  
building the OSR entry point.  The failure is caused by one of the  
incoming locals containing an address.  We fail this assert:

   assert(_gvn.type(l)->higher_equal(type), "must constrain OSR  
typestate");

because _gvn.type(l) returns TypeRawPtr::BOTTOM and type is a Constant  
RawPtr.

(dbx) p _gvn.type(l)->dump()
rawptr:BotPTR
(dbx) p type->dump()
0x00000219
(dbx) p osr_block->flow()->print()
   ====================================================
   #0  rpo#0  [108 - 119) Stored locals: { }

   State : locals 22, stack 0, monitors 0
     local  0 : com/cyc/tool/subl/jrtl/nativeCode/subLisp/SubLThread
     local  1 : com/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject
     local  2 : com/cyc/tool/subl/jrtl/nativeCode/type/core/ 
SubLObjectBase
     local  3 : com/cyc/tool/subl/jrtl/nativeCode/type/symbol/SubLNil
     local  4 : com/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject
     local  5 : com/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject
     local  6 : com/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject
     local  7 : com/cyc/tool/subl/jrtl/nativeCode/type/core/SubLObject
     local  8 : bottom
     local  9 : bottom
     local 10 : bottom
     local 11 : bottom
     local 12 : bottom
     local 13 : bottom
     local 14 : bottom
     local 15 : bottom
     local 16 : bottom
     local 17 : bottom
     local 18 : bottom
     local 19 : bottom
     local 20 : bottom
     local 21 : address(537)
   Successors : 2
     #3154 rpo#1  [119 - 152)
     #3153 rpo#2  [305 - 314) irred
   Exceptions : 1
     #1  rpo#3  [317 - 322) -- java/lang/Throwable
   ====================================================

First off I'm surprised that isn't true.  It seems to me that a  
constant RawPtr should be BOTTOM, or am I reading that incorrectly.   
When I went back to a version of hotspot prior to the ciTypeFlow  
changes for phi elimination I found that I didn't hit this assert  
because the local in question was bottom.  Looking through the  
ciTypeFlow output I could see lots of copies of the entry block and  
some had bottom for this particular local and some didn't.  So somehow  
the ciTypeFlow fixes changed which copy ended up being the considered  
the OSR entry point.  My question is which version of the block should  
ciTypeFlow consider to be the canonical one suitable for use by the  
parser?  It seems like there's a conflict between the cloning for jsr/ 
ret and producing a canonical version suitable for the entry point.

tom