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

Status: RESOLVED INVALID

(DevTools :: Memory, defect)

Description

[Jim Blandy :jimb]

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

Comment 1

[Axel Kratel]

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

[Panos Astithas (he/him) [:past] (please ni?)]

Besides an add-on, a possibly interesting alternative option for shipping a rough and experimental tool would be a GCLI command.

Comment 3

[Rob Campbell [:rc] (:robcee)]

(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.

Comment 4

[Jim Blandy :jimb]

(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).

Comment 5

[Jim Blandy :jimb]

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.

Comment 6

[Jim Blandy :jimb]

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.

Comment 7

[Julien Wajsberg [:julienw]]

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.