LIRFrameState locals[0]

[Deneau, Tom]

Ah, that makes sense.
Looking more closely I see that in my case, it was a "this" pointer that was used in the early bcis of the method but not used after the bci of the deopt.

-- Tom

> -----Original Message-----
> From: Tom Rodriguez [mailto:tom.rodriguez at oracle.com]
> Sent: Thursday, January 09, 2014 5:12 PM
> To: Deneau, Tom
> Cc: graal-dev at openjdk.java.net
> Subject: Re: LIRFrameState locals[0]
> 
> Maybe it's not live?  Locals which aren't needed for execution of the
> byte codes aren't captured for deopt.  -G:-OptLivenessAnalysis turns it
> off.
> 
> tom
> 
> On Jan 9, 2014, at 2:51 PM, Deneau, Tom <tom.deneau at amd.com> wrote:
> 
> > I've noticed that sometimes when I get a DeoptimizationNode, the
> attached LIRFrameState for locals[0] sometimes has a type of illegal.
> Why might this be?
> >
> > info.topFrame.numLocals = 4
> > info.topFrame.values[0].kind = "illegal"
> > info.topFrame.values[1].kind = "Object"
> > info.topFrame.values[2].kind = "int"
> > info.topFrame.values[3].kind = "int"
> >
> > -- Tom
> >
>