Fix outdated comments explaining XPCWrappedJS lifetime. No bug. r=mccr8
authorBoris Zbarsky <bzbarsky@mit.edu>
Wed, 24 Apr 2019 20:54:20 +0000
changeset 530050 da5f153ddda15479ed4f984acf361874c7b39492
parent 530049 1fae6818d4e4185f914a8b7b39afc8d906a5e2d4
child 530051 2a3c00a2d76186a205fd4e6d0496c28748cb2f3a
push id11265
push userffxbld-merge
push dateMon, 13 May 2019 10:53:39 +0000
treeherdermozilla-beta@77e0fe8dbdd3 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewersmccr8
milestone68.0a1
first release with
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
last release without
nightly linux32
nightly linux64
nightly mac
nightly win32
nightly win64
Fix outdated comments explaining XPCWrappedJS lifetime. No bug. r=mccr8 Differential Revision: https://phabricator.services.mozilla.com/D28220
js/xpconnect/src/XPCWrappedJS.cpp
--- a/js/xpconnect/src/XPCWrappedJS.cpp
+++ b/js/xpconnect/src/XPCWrappedJS.cpp
@@ -35,20 +35,21 @@ using namespace mozilla;
 // When the refcount of a rooting wrapper drops to 1, if there is no weak
 // reference to the wrapper (which can only happen for the root wrapper), it is
 // immediately Destroy()'d. Otherwise, it becomes subject to finalization.
 //
 // When a wrapper is subject to finalization, the wrapper has a refcount of 1.
 // It is now owned exclusively by its JS object. Either a weak reference will be
 // turned into a strong ref which will bring its refcount up to 2 and change the
 // wrapper back to the rooting state, or it will stay alive until the JS object
-// dies. If the JS object dies, then when XPCJSContext::FinalizeCallback calls
-// FindDyingJSObjects it will find the wrapper and call Release() in it,
-// destroying the wrapper. Otherwise, the wrapper will stay alive, even if it no
-// longer has a weak reference to it.
+// dies. If the JS object dies, then when
+// JSObject2WrappedJSMap::UpdateWeakPointersAfterGC is called (via the JS
+// engine's weak pointer zone or compartment callbacks) it will find the wrapper
+// and call Release() on it, destroying the wrapper. Otherwise, the wrapper will
+// stay alive, even if it no longer has a weak reference to it.
 //
 // When the wrapper is subject to finalization, it is kept alive by an implicit
 // reference from the JS object which is invisible to the cycle collector, so
 // the cycle collector does not traverse any children of wrappers that are
 // subject to finalization. This will result in a leak if a wrapper in the
 // non-rooting state has an aggregated native that keeps alive the wrapper's JS
 // object.  See bug 947049.