Closed Bug 957791 Opened 11 years ago Closed 6 years ago

Firefox should tell me why particular JS objects aren't being freed.

Categories

(DevTools :: Memory, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: jimb, Unassigned)

References

(Depends on 1 open bug)

Details

Alex Poirot (:ochameau) did a nice hack that helps you find out whether an object you expect to become garbage has actually been collected, and if not, why not. This tool can't help you until you have identified a problematic object --- but that is often possible from other context. It's used like this: prologue) The developer identifies, through debugging and deduction, that the browser is retaining some of a given set of objects longer than it ought. 1) The developer edits their code so that, while the objects are still in active use and the developer knows where to find them, the code passes them to a function provided by the tool. 2) This function maintains a set of the objects it has received. This set references its member objects "weakly": if an object would otherwise be GC'd, it is removed from the set (and GC'd); but as long as the object has other non-weak references to it, it stays in the set. 3) At the point where the developer expects the objects (or some of the objects) to have become unreachable, she opens up a devtool display which lists whatever objects remain in the set, and the paths by which they can be reached. Where possible, these paths will be JavaScript expressions that refer to the object: x.a[42].y --- but that's not always possible, in which case we'll do the best we can: [[event loop]].[[setTimeout queue]].[[500ms]].[[environment]].x
Blocks: perf-kanban
Jim, thanks for logging this. As per our discussion on IRC, the "prologue" is precisely the "other" tools we need, i.e. something that shows the developer to begin with that there are problems. We need the prologue tool as a higher priority. If this functionality is available earlier, that's fine, until we have created the tool for the "prologue", we can try to pre-release this functionality via a plugin, and then integrate it with the main tool later.
Besides an add-on, a possibly interesting alternative option for shipping a rough and experimental tool would be a GCLI command.
(In reply to Jim Blandy :jimb from comment #0) > prologue) The developer identifies, through debugging and deduction, that > the browser is retaining some of a given set of objects longer than it ought. This is the important first step.
(In reply to Rob Campbell [:rc] (:robcee) from comment #3) > > prologue) The developer identifies, through debugging and deduction, that > > the browser is retaining some of a given set of objects longer than it ought. > > This is the important first step. Understood. Let me explain why I brought this up: The full tool will require a certain set of platform-level analyses to work: call them A, B, C, D, and E. This tool can be implemented with only A and B. It's also something that our developers found valuable when Alex first implemented it (using cycle collector APIs) as an add-on, despite its shortcomings. In practice, developers know what role they intend an object to play, including when they intended for it to go away. What's great about this tool is that it's a nice fit between what the developer often knows (the object's intended lifetime) and what only we can find (the retaining path).
I understand that we don't want to make a bad first impression. But I do think it's good to provide things - perhaps without public fanfare - that people find useful, and earlier is better.
A console-only UI for this would be totally fine. Then, nobody would mistake it for an attempt to provide "Heap Profiling Features" - but it'd be available, and we could start helping people out sooner.
Component: Developer Tools: User Stories → Developer Tools: Memory
Product: Firefox → DevTools
I think the dominator view, while not perfect, implements part of the wanted feature here. I'm gonna close this bug, but please reopen if you think otherwise, or file new bugs targeting this view.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.