Bug 944260 Comment 8 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Jim Blandy :jimb from comment #7)
> In bug 1550440, Brian said:
> > [F]inding the reachable scripts without involving the GC would be really expensive, even slower than a full non-incremental GC.
> 
> The idea is that this new API could continue to use `Zone::cellIter`, just as `findScripts` does now. But, since it doesn't actually return the set of affected scripts to JS, and Debugger only gets notified when some matching script actually runs, the visible behavior is entirely deterministic.

Hmm, so I have some concerns:

- The bugs I've seen related to unpredictable debugger behavior wrt GC have been concerned with sources not being shown in the debugger, rather than the scripts themselves.  dbg.findSources() is implemented separately from dbg.findScripts() and also uses cell iteration / unpredictable GC behavior.  Does this bug encapsulate findSources() as well?

- If so, right now the scripts which findScripts finds are used to determine the sources which the client will ultimately show in the sources pane.  What we do right now is show all the sources on the page that haven't been GC'ed, and with this change it seems like we will only show the sources whose scripts have run since the debugger was attached.  Is this change in behavior expected / desired?  The current behavior seems more intuitive to me.

- Similarly, for findScripts() itself the server uses the scripts found to populate the breakpoint positions which the client uses to decide where the user can set breakpoints.  If the debugger only knows about scripts that have executed since it attached, users will only be able to install breakpoints on those scripts, which seems especially non-intuitive.

The last point could be worked around by reparsing a source to determine its breakpoint positions, which would make the breakpoint positions GC insensitive but would entail more work for the server to do.  That would be an improvement I think but still doesn't address the larger user-facing problem of showing an incomplete set of sources when attaching to existing tabs.
(In reply to Jim Blandy :jimb from comment #7)
> In bug 1550440, Brian said:
> > [F]inding the reachable scripts without involving the GC would be really expensive, even slower than a full non-incremental GC.
> 
> The idea is that this new API could continue to use `Zone::cellIter`, just as `findScripts` does now. But, since it doesn't actually return the set of affected scripts to JS, and Debugger only gets notified when some matching script actually runs, the visible behavior is entirely deterministic.

Hmm, so I have some concerns:

- The bugs I've seen related to unpredictable debugger behavior wrt GC have been concerned with sources not being shown in the debugger, rather than the scripts themselves.  dbg.findSources() is implemented separately from dbg.findScripts() and also uses cell iteration / unpredictable GC behavior.  Does this bug encapsulate findSources() as well?

- If so, right now the sources which findSources finds are used to determine the sources which the client will ultimately show in the sources pane.  What we do right now is show all the sources on the page that haven't been GC'ed, and with this change it seems like we will only show the sources whose scripts have run since the debugger was attached.  Is this change in behavior expected / desired?  The current behavior seems more intuitive to me.

- Similarly, for findScripts() itself the server uses the scripts found to populate the breakpoint positions which the client uses to decide where the user can set breakpoints.  If the debugger only knows about scripts that have executed since it attached, users will only be able to install breakpoints on those scripts, which seems especially non-intuitive.

The last point could be worked around by reparsing a source to determine its breakpoint positions, which would make the breakpoint positions GC insensitive but would entail more work for the server to do.  That would be an improvement I think but still doesn't address the larger user-facing problem of showing an incomplete set of sources when attaching to existing tabs.

Back to Bug 944260 Comment 8