So to take the example from the article, if your optimising compiler unrolls the loop so there are four loop iterations per jump, and i is incrementing 0, 4, 8, 12... if you set a conditional breakpoint on i=10, how does it work out that it needs to break at the earlier safepoint (when i=8) and switch to the non-optimised code?
I don't think that needs to happen. From the article:
"Basically, we re-enter a clone of the loop from above…. a clone specially made to be re-entered at any iteration"
This is put forward as the explanation for how variables are mutated in the debugger, but as a mechanism for "un-unrolling" the loop it probably serves to support such conditional breakpoints too.