3 ms·
The issue with debugging JITed code is not that the optimizer may be incorrect, but rather that optimization wreaks havoc on the correspondence between source c
by StefanKarpinski 12y ago
The issue with debugging JITed code is not that the optimizer may be incorrect, but rather that optimization wreaks havoc on the correspondence between source code and what actually executes – things happen in a different order or not at all, stack frames don't correspond to function calls, etc. This makes the debugging experience pretty confusing. To get a sense of this, try using gdb/lldb on code compiled at -O3 with -g turned on so that you still have debugging symbols. Things are weird. When debugging AOT compiled code, one avoids this confusing experience by recompiling the entire program in debug mode with optimizations off. In a JIT environment, what do you do? This article describes a clever approach: dynamically deoptimize the stack and transfer control from optimized code to non-optimized code, then debug the simple, non-optimized version of your program where what's executed lines up nicely with the source code.
- amelius 12y agoThings happening out of order should never be observable. So this should not be an issue.
- gsg 12y agoThe 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.
- StefanKarpinski 12y agoYou may be thinking of CPUs doing out-of-order execution, which is indeed unobservable. Compilers, however, also reorder operations which is very much observable.