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.
tom
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