Bug 93661

In an email, abarth wrote: -------- In reading the MutationObservers code recently, I had the following questions. Although these questions are phrased in terms of V8, I have the same questions w.r.t. the JavaScriptCore implementation. 1) Do MutationObservers leak memory? Specification, consider the following JavaScript: function foo() { function bar() { alert(observer.qux); } var observer = new MutationObserver(bar); } How does the memory we allocate for WebCore::MutationObserver ever get freed? It appears that A) MutationObserver has a RefPtr<MutationCallback> m_callback, which (concretely) is of type V8MutationCallback B) V8MutationCallback has a v8::Persistent<v8::Object> m_callback, which is a handle to the JavaScript function bar(). C) bar() is a closure that contains observer, which (concretely) is of type V8MutationObserver, which holds a reference to MutationObserver via the wrapper map. That appears to be a reference cycle that loops through the V8 and C++ heaps, which means we'll leak. Is there some mechanism that saves us from this leak? 2) What keeps the MutationObserver JavaScript wrapper alive? Specification, consider the following JavaScript: function bar(mutations, observer) { alert(observer.qux); } function foo() { var observer = new MutationObserver(bar); observer.qux = "PASS"; observer.observe(document.body, ...); } Once foo() completes, there are no longer any references to observer in the V8 heap, so the V8 garbage collector will collect the V8MutationObserver object (and we'll remove it from the wrapper map). Presumably Node::registerMutationObserver will cause the DOM to retain the underlying WebCore::MutationObserver object. At some point in the future, the mutation observer will trigger and call bar. The second argument to bar is the MutationObserver object, which will get a fresh JavaScript wrapper because the previous JavaScript wrapper is no longer present in the wrapper map. The new wrapper will not have property qux because that property was stored on the old wraper, which was discarded. --------- The answers to Adam's questions here is that both (1) and (2) are problems. I suspect that solving (1) (by pushing the circular references into the JS heap) will also solve (2) in the process.