ciTypeFlow, osrs and jsr/ret

[Tom Rodriguez]

I think the JsrSets are really the cause of the excessive cloning in  
ciTypeFlow but my fix for it isn't right.  The core of the problem is  
that the JsrSet is maintained separately from the StateVector and the  
only way to remove a jsr from the JsrSet is to execute a ret.  So  
instead I'm thinking of adding logic in flow_block that trims jsrs  
from the JsrSet based on which addresses are actually live in the  
StateVector according to methodLiveness.  We end up with a little  
block duplication because we're doing it somewhat late but we can't do  
it earlier because we don't necessarily have a state earlier.

This brings me to the other mystery here which was why we were seeing  
addresses in locals at the OSR point.  I'd forgotten about the logic  
in liveness_at_bci that claims all locals are live if a debugger has  
requested access to local.  We also do this in CompileTheWorld mode so  
that's why I was seeing it.  I think the right fix is to treat all  
address locals as dead at the OSR point irrespective of what liveness  
says.

Anyway, fixing the excessive cloning in ciTypeFlow seems good but I'm  
not sure I want to use it as the fix for 6854812 since I'd like to  
include a fix for 6854812 in hs16.  I filed 6877170 for the ciTypeFlow  
cloning and will go with a more targeted fix for 6854812.  Anyway, if  
you're interested the cloning fix check out http://cr.openjdk.java.net/~never/6877170 
.

tom

On Aug 27, 2009, at 10:42 PM, John Rose wrote:

> Yes!  Sounds good.  -- John
>
> On Aug 27, 2009, at 2:49 PM, Tom Rodriguez wrote:
>
>> I added some logic in compute_exceptions to pop the the last jsr  
>> record if tos is a return address.  This results in there only  
>> being 61 blocks instead of almost 3000.  It also fixes the original  
>> problem in 6854812.
>