1547089 - Instant Stepping

Status: RESOLVED DUPLICATE of bug 1556813

(Core Graveyard :: Web Replay, enhancement, P5)

Description

[Brian Hackett [Laid off!]]

Currently, when stepping around within a recording while using web replay, we have to take the process that is stepping to the target of the step (rewinding if necessary) so that the location of the target can be determined and the state there queried. While not horribly slow, this is slower than the normal non-replaying debugger, and used naively with a cloud based architecture this will be much slower.

It would be better if stepping around within a recording happened pretty much instantly. When we are replaying we can inspect the state at every point of a program's execution, and if we are paused within a frame we could analyze the state at every nearby place the user could step to, including everything the client will need in order to update the UI when pausing at those places. When the user steps, the information is immediately available and the limiting factor is how fast the client can update the UI with that information.

The information included will be what the client needs to update the UI, and probably not much more. If the user steps and then starts evaluating things or inspecting object trees, we will need a replaying process at the execution point in order to resolve those queries (this is a sort of the hybrid analysis approach we are moving towards). This won't be instantaneous, though it should be quick (less than a second) and unnoticeable in most scenarios.

Stepping forward at the very end of the recording will still be slow, since we have to extend the recording with each new step. It would be good to discourage this: it's much better for users to record the behavior they want to debug, and then rewind and step around inside to understand what happened. Maybe the inherent slowness of the stepping will act to discourage this, though.

We have to be careful here when a frame has bazillions of steps within it, like a long running loop. Ranges where we are capturing all steps should be based on the progress counter (bumped at each loop head) instead of particular frames.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:bhackett, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch

This patch extends the stuff in bug 1547093 to allow pause data to be prefetched for the various steps in a frame, so that they can be stepped to instantly, without having to bring a replaying process to the target of the step. Prefetching this data is quite simple, but the main work going on in this patch is to rework how frame steps are obtained. Instead of bringing a replaying process to the start of the frame and having it step through it (this can take some time, mostly the bringing of a process to the target point), the data computed during scanning has been augmented so that the steps can be found entirely from scan data. The extra data needed is knowledge of where EnterFrames occur (so step-ins can be resolved) and where exceptional OnPops occur (so the endpoint of frames that throw exceptions can be resolved).

Comment 3

[Brian Hackett [Laid off!]]

I'm folding this into bug 1556813.