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)
DevTools
Memory
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
Updated•11 years ago
|
Blocks: perf-kanban
Comment 1•11 years ago
|
||
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.
Comment 2•11 years ago
|
||
Besides an add-on, a possibly interesting alternative option for shipping a rough and experimental tool would be a GCLI command.
Comment 3•11 years ago
|
||
(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.
Reporter | ||
Comment 4•11 years ago
|
||
(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).
Reporter | ||
Comment 5•11 years ago
|
||
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.
Reporter | ||
Comment 6•11 years ago
|
||
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
Updated•6 years ago
|
Product: Firefox → DevTools
Comment 7•6 years ago
|
||
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.
Description
•