The only reason things happening out of order is invisible is because implementors jump through the kinds of hoops described in the article. One way to underst

The only reason things happening out of order is invisible is because implementors jump through the kinds of hoops described in the article. One way to understand the requirement for deoptimization is to to think about where the programmer can observe the difference between an optimized construct and the naive version. In regular execution there are relatively few places where the state of the program is observable, allowing freedom to aggressively optimize - under the debugger there are no places where the state of the program is unobservable.