Provide access to scoped variables in optimized code via breakpoints |
||||||
Issue descriptionRelevant design document: https://docs.google.com/document/d/1AnsQpiWdtEuacKoYloVktHcX2m2fnuWmuFjiLaijxs4 Users of DevTools and V8 debugger have been complaining for a long time that debugger breaks in optimized code are less useful. Variables on the stack may be optimized away, and modifying them is not possible either. Some users have resorted to inserting eval() to disable optimization. Also see https://twitter.com/bmeurer/status/978858815553724416?s=19 I suggest adding an option to Debugger.enable to disable optimization in V8. But I don't know how to surface this in DevTools. I also assume that we don't want to disable optimization by default due to performance implications. I could also imagine a second option to force context allocation so that the entire scope chain of a function can always be fully inspected. That changes memory profile due to more contexts being allocated though. Both options would be equivalent to building C++ in debugger mode. WDYT?
,
Mar 28 2018
,
Mar 28 2018
As per offline discussion, what we could do is this: On setting the first breakpoint or enabling break-on-exception, deoptimize all existing optimized code, and only produce optimized code with liveness analysis off. This way, inspecting values on the stack at a break will no longer yield "optimized_out" results. This will have a small impact on performance and memory profile, but a lot less than disabling TurboFan altogether. I propose making this implicit, i.e. no user interaction is required to explicitly turn this feature on/off. What this does not solve are these situations: - Enabling DevTools late and pausing on next statement. - Debugger statement.
,
Mar 28 2018
Here's a design document to capture these ideas: https://docs.google.com/document/d/1AnsQpiWdtEuacKoYloVktHcX2m2fnuWmuFjiLaijxs4
,
Mar 28 2018
,
Mar 28 2018
>> On setting the first breakpoint or enabling break-on-exception 'Break on exception' is often on by default, so it would not be a great trigger, especially for those opening DevTools for performance profiling. >> I propose making this implicit Whatever the solution is, making it implicit is in line with the devtools debugging principles. Doing something along the lines with the #1 would be ideal. Alternatively, this feature is not worth deopting the world upon debugging.
,
Mar 29 2018
,
Mar 29 2018
,
Mar 29 2018
,
Mar 29 2018
The following revision refers to this bug: https://chromium.googlesource.com/v8/v8.git/+/1cf0fc80adae971afce07987d61d11f42926139f commit 1cf0fc80adae971afce07987d61d11f42926139f Author: Benedikt Meurer <bmeurer@chromium.org> Date: Thu Mar 29 09:03:11 2018 [turbofan] Allow to disable liveness analysis in CompilationInfo. This way we can teach the debugger to disable liveness analysis when running with (potential) breakpoints, so that the developers always have (read) access to all scoped variable values. Bug: v8:7608 , chromium:826613 Change-Id: I7e6cea105f111c99d2620546144201624dfe1d8b Reviewed-on: https://chromium-review.googlesource.com/985838 Reviewed-by: Yang Guo <yangguo@chromium.org> Reviewed-by: Tobias Tebbi <tebbi@chromium.org> Commit-Queue: Benedikt Meurer <bmeurer@chromium.org> Cr-Commit-Position: refs/heads/master@{#52293} [modify] https://crrev.com/1cf0fc80adae971afce07987d61d11f42926139f/src/compilation-info.cc [modify] https://crrev.com/1cf0fc80adae971afce07987d61d11f42926139f/src/compilation-info.h [modify] https://crrev.com/1cf0fc80adae971afce07987d61d11f42926139f/src/compiler/bytecode-graph-builder.cc [modify] https://crrev.com/1cf0fc80adae971afce07987d61d11f42926139f/src/compiler/bytecode-graph-builder.h [modify] https://crrev.com/1cf0fc80adae971afce07987d61d11f42926139f/src/compiler/js-inlining.cc [modify] https://crrev.com/1cf0fc80adae971afce07987d61d11f42926139f/src/compiler/pipeline.cc
,
Sep 21
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by bmeu...@chromium.org
, Mar 28 2018Components: Blink>JavaScript>Compiler