716006 - Don't traverse NodeInfoManager so much

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

If NodeInfoManager has mDocument and mDocument is in CC generation, it certainly
keeps NodeInfoManager alive, since mDocument owns the manager, and the manager
will be deleted only when document is deleted.

Comment 1

[Andrew McCreight [:mccr8] (PTO until 12-2)]

What is the path from a document to the nsNodeInfoManager?  Can we statically check that path, or is it just from elements in the document?

Comment 2

[Johnny Stenback (:jst)]

Comment on attachment 586510 [details] [diff] [review]
patch

r=jst

The path from the document to the nodeinfo manager is a direct strong reference (from nsIDocument::mNodeInfoManager).

Comment 3

[Andrew McCreight [:mccr8] (PTO until 12-2)]

Comment on attachment 586510 [details] [diff] [review]
patch

Review of attachment 586510 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. It might be a good idea to add an assertion that checks the document really holds onto the infomanager, but unlike some of the patches that seems like a very fundamental thing and is unlikely to change.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

If nodeinfomanager has a document, it is created when document::init is called, and 
document does not ever release it before dtor.
Note, nodeinfomanager does not own document, if document doesn't have any child nodes connected to it.
This way nodes in the document own their ownerDocument, but just having document alive doesn't
create a cycle to itself.

If document is marked to be in generation, it is either in some docshell/contentviewer or it is 
an XBL document hold by xul cache.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

https://hg.mozilla.org/mozilla-central/rev/0674f2bdd78b