question about bci in LIRFrameState for DeoptimizeOp

[Deneau, Tom]

Also, if a draft of Gilles'  paper is available for review, that would be great.

-- Tom

-----Original Message-----
From: Thomas Wuerthinger [mailto:thomas.wuerthinger at oracle.com] 
Sent: Wednesday, November 20, 2013 2:40 PM
To: Deneau, Tom
Cc: graal-dev at openjdk.java.net
Subject: Re: question about bci in LIRFrameState for DeoptimizeOp

Graal understands that it can safely replay bytecodes without side effects. Therefore the target bci of a deoptimization will reflect the last side effecting instruction (or the beginning of the method if no such instruction exists). Gilles wrote a paper describing in more details how deoptimization works in Graal and we will publish it shortly as part of the Graal documentation. - thomas

On 20 Nov 2013, at 21:17, Deneau, Tom <tom.deneau at amd.com> wrote:

> I was looking at the AMD64DeoptimizeOp.emitCode routine which is
>        AMD64Call.directCall(tasm, masm, 
> tasm.foreignCalls.lookupForeignCall(UNCOMMON_TRAP), null, false, 
> info);
> 
> When I look at the LIRFrameState info which is passed to UNCOMMON_TRAP, the bci always seems to be 0.
> Why is that?
> 
> For example, compiling this small snippet thru AMD64 backend
>    public int intFromArray(int[] ary, int idx) {
>        return ary[idx];
>    }
> 
> with bytecodes
>  public int intFromArray(int[], int);
>    Code:
>       0: aload_1       
>       1: iload_2       
>       2: iaload        
>       3: ireturn       
> 
> when I get to AMD64DeoptimizeOp.emitCode, I see info = "at 
> com.oracle.graal.compiler.test.BasicTest2.intFromArray(BasicTest2.java:46) [bci: 0]
>            |0  |1     |2    
>   locals:  |-  |v0|a  |v1|i "
> 
> I would have expected the bci in this case to be 2, referring to the iaload instruction.
> 
> -- Tom
> 
>