If we deoptimize at a SafePoint (as opposed to a call site) we'll start executing the next bytecode in the interpreter. If the reported bytecode is a branch and the branch is taken, we'll ignore the taken branch and act as if the branch is not taken. Can happen for backwards branches at loop ends, for instance.

BCI5:
        ....
BCI16: ifne BCI5 <-- safepoint here will fail
BCI18:

See attached sf.java. Execute it on a multi-processor wintel box with these arguments:

java_g -server -XX:+ShowSafepointMsgs -Xcomp -XX:+DeoptimizeALot -XX:DeoptimizeALotInterval=0 -XX:CompileOnly=.loop sf

The loop will exit prematurely.

Root cause: safepoint needs to report a BCI of an instruction which has no control flow, even exceptions. It needs debug info for the state after that bytecode has executed. If a de-opt happens the next sequential bytecode will execute, so the next sequential bytecode better be the right one to execute!

Thanks to Srdjan for finding this one.

Cliff 12/20/2000