1547093 - Instant Breakpoint Hits

Status: RESOLVED DUPLICATE of bug 1556813

(Core Graveyard :: Web Replay, task)

Description

[Brian Hackett [Laid off!]]

When rewinding or playing through the recording, we have to scan backward or forward for breakpoint hits, which can be pretty slow when the breakpoint hits are far apart. Breakpoints are a rather antiquated method for interacting with the debugger in comparison with logpoints plus warping, but for users that want to use them we can provide a similarly fast experience by leveraging those features. When a user creates a breakpoint, we could treat it as a hidden logpoint and generate the information needed to warp to all the hits on that breakpoint. If they play forward or rewind, we can determine the execution point of the next breakpoint hit the resumption will land at, and warp there directly.

Comment 1

[Brian Hackett [Laid off!]]

Attachment: patch

This patch prefetches pause and repaint data for hits on installed breakpoints. Once the data has been gathered, the replay debugger can use it to immediately pause when rewinding or playing forward to breakpoint hits. Graphics are updated immediately, and the server can use the pause data immediately in response to client requests to update the pause state. Because the pause data has everything the server will need (as long as there aren't any watched expressions or anything that require extra evaluations), the pause can be completed before a replaying process even arrives at the point where the pause is happening at.

The logic to do this is all pretty straightforward. The main change is that management of graphics when repainting had to be reworked. Instead of allowing replaying processes to paint directly into the graphics shmem, the replaying process doesn't touch the shmem when repainting but rather paints into its own buffer, converts it to a PNG image, and sends it to the middleman. When the middleman wants to paint the graphics at that point, it just draws the PNG. On my machine the raw graphics memory for a window is ~10 MB, but the PNG image for a relatively simple page like TodoMVC is only a few hundred KB.

This fix is nice because it also takes care of one of the big outstanding problems with cloud integration --- passing graphics data from a remote replaying process to the user without using a ton of bandwidth.

Comment 2

[Brian Hackett [Laid off!]]

I'm folding this into bug 1556813.