ciTypeFlow, osrs and jsr/ret

Tom Rodriguez Thomas.Rodriguez at Sun.COM
Thu Aug 27 14:49:14 PDT 2009

I've seen problems in the past where methodLiveness says things are  
live that actually aren't.  The cases I remember always involved jsr/ 
ret and I don't remember tracking any of them down to a root cause.   
methodLiveness is a conservative analysis so it will say things are  
live that actually aren't.  From the cpp:

// The algorithm is approximate in many respects.  Notably:
// 1. We do not do the analysis necessary to match jsr's with the  
appropriate ret.
//    Instead we make the conservative assumption that any ret can  
return to any
//    jsr return site.
// 2. Instead of computing the effects of exceptions at every  
instruction, we
//    summarize the effects of all exceptional continuations from the  
block as
//    a single set (_exception_exit), losing some information but  
simplifying the
//    analysis.

But I don't think methodLiveness is the real problem here, though it  
would mask this problem if it were precise.  Additionally ciTypeFlow  
doesn't consult methodLiveness directly.  It's only consulted once we  
start parsing.  ciTypeFlow is precise since it performs the jsr/ret  
inlining so it should be able to do the right thing but the answers it  
gets aren't as precise as I would expect.  Maybe it has to do with  
maintenance of the JsrSets?

Looking at the CITraceTypeFlow output, one thing that seems wrongish  
is that when handling exception edges for blocks which end with jsr,  
the currently active jsr is included in the jsrs which are active in  
the exception handlers.  The jsr is atomic so it's not actually live  
in the exception handler which could lead to a lot of extra cloning.   
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.


On Aug 27, 2009, at 12:52 PM, John Rose wrote:

> On Aug 27, 2009, at 12:36 PM, Tom Rodriguez wrote:
>> We specifically disallow osr's into blocks with live jsr's.  
>> ciTypeFlow checks for this and bails out if it occurs.
> I thought so.  So what is that raw address 537 doing in local 21?   
> Is it really dead, but the liveness analysis is failing to prove it  
> so?
> -- John

More information about the hotspot-compiler-dev mailing list