I implied that the popups are using the parent document to communicate with each other (I thought I stated this?). If you retain the parent document after it is closed in order to keep the child documents working, now you have a cycle that requires a cycle collector (parent -> children, children -> parent); if the parent document is released upon being closed, you are now making GC visible to the child windows and their parent reference is implicitly a weak reference.
The window and children example is intended to illustrate that manual cycle-breaking is non-trivial; in this case it requires a robust reference counting mechanism and code audits to ensure reference increments/decrements are carefully matched and put in every necessary location. JS doesn't have a trivial solution for scoped references like C++ does, either... I mentioned self-hosting to illustrate the need for weak references: It's fine that the JS environment has no weak reference alternative as long as all the 'hard stuff' is written in C++, but it seems as if there are reasons to move and more functionality into JS in order to create new optimization opportunities and reduce the security attack surface. Given this, eventually the lack of weak reference options in JS will prevent components with such cycles from being easily moved to JS. Even if Gecko can be carefully constructed to never run up against this problem, it is certain that eventually other applications will hit it. Whether or not WRs are the right solution for current JS leak problems, philosophical disagreements with GC visibility in JS are not a good reason to rule out being able to solve real application design problems. Manual cycle breaking is simply more error prone in most scenarios. (Sometimes you really do need instantaneous cleanup, in which case you have to manually break cycles.) The lack of WRs will also become increasingly problematic as the web becomes a compilation target for more languages and frameworks. asm.js is not a solution to this as it punts on the problem entirely, forcing the end user to implement their own GC (with weak references) to bypass the fact that the JS garbage collector is intentionally crippled. On Fri, Mar 21, 2014 at 9:20 PM, Jason Orendorff <jorendo...@mozilla.com> wrote: > On 3/21/14, 10:23 PM, K. Gadd wrote: >> A hypothetical scenario (please ignore any minor detail errors, I'm >> using this to illustrate the scenario): Let's say I have a main >> document and it spawns 3 popup windows as documents. The popup windows >> have references to the parent document and use them to post messages >> to the parent document for the purposes of collaboration. Now, let's >> say I want the popups to *keep working* even if the parent document is >> closed. > > By "keep working" do you mean that the popup windows should still be > able to post messages to the main document, and its event handlers > should still be firing? > >> In this scenario, the popups *need* to retain their references >> to the parent document, but we don't want to leak the parent document >> after all 3 of them are closed. > > Why are weak references useful here? Suppose we're just using strong > references, i.e. the web as it is today. After the main window and all > three popups are closed, why would the parent document leak? > > -j > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
