1532844 - Investigate ways to address JSScript GCing interfering with our ability to query for available breakpoint positions

Status: NEW

(DevTools :: Debugger, enhancement, P3)

Description

[Logan Smyth [:loganfsmyth]]

One known potential issue with the new breakpoint specificity (https://bugzilla.mozilla.org/show_bug.cgi?id=breakpoint-specificity) work is that, if a script has executed and the engine knows that some part of it (a JSScript) won't run again, it may opt to GC that part.

This means that if the user clicks to add a breakpoint at a location that falls at a GCed location, we will not have any way to know what breakpoints would be available there.

The primary case where this happens is top-level logic in a given script. While functions and things are most likely exported or used my something that is exported, and thus won't be GCed, the top-level execution environment just runs once and then never again, so much of the time the engine will at some point GC it.

If a user wanted to add a breakpoint and then refresh the page to hit it, they may be unable to do so.

The few possible approaches that come to mind are

1. Explicitly hold strong references to every JSScript that we ever see.
   This has the downside that JS code is free to use eval to create an unbounded number of JSScript objects, which could potentially lead to the debugger introducing a memory leak by preventing the evaled scripts from being GCed.
   That said, we also hold strong links to evaled Source objects as far as I know, so it is possible that the memory overhead of holding strong links to all JSScripts is an acceptable side-effect of opening the devtools. We could also explore heuristics, like only strongly holding source created without eval, or strongly holding scripts, but only for a period of time.

2. Eagerly query for all breakpoint positions as soon as we see a script, so if it is GCed in the future, we will still have the data we need.
   This would still lead to a slow buildup of memory, but it would allow the scripts themselves to be GCed at least, potentially reducing the memory overhead. That said, I don't actually have numbers to back that up.
   This could potentially also slow down page load times for the debuggee page, since the debugger would have to do all this work as it loaded.

3. Have SpiderMonkey itself be able to regenerate a JSScript for a given location if the previous one has been GCed, so that breakpoint information can be queried from it.
   Likely a ton of work, possibly prohibitively so.

NOTE:
We should do some investigation in this issue to figure out of this issue applies when the devtools have already been opened, or just if you open the devtools on an existing page. It is possible that the cases we need to handle vary based on those two cases.

Comment 2

[Jason Laster [:jlast]]

Open Questions:

1. open devtools on a page later on bug 1539547
2. reloading
3. add a breakpoint after a GC

Comment 3

[Jason Laster [:jlast]]

perhaps we try to re-think findScripts

Comment 4

[Jan Honza Odvarko [:Honza] (always need-info? me) PTO July 8 - 26]

Just a simple test case, so anyone can repro this:

1. Load https://firefox-dev.tools/debugger-examples/examples/todomvc/
2. Open the debugger, select js/app.js
3. Try to set BP on line 11 (line number is not disabled), but no BP created -> BUG

If you can add BP in step #3
4) Close and open the Toolbox
5) Repeat step #3

Honza