On 03/21/2014 08: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. 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.
Thanks for a concrete example. Weak refs solve a broad class of problems and provide a very tempting abstraction. Sadly, they also introduce contradictory goals to your GC tuning: you want to defer collection as long as possible to reduce overhead and therefore improve performance, but you added those weak refs for a reason which means you depend on them happening "soon". So to serve whatever the goals of that weak ref usage are, you want collection to be prompt. And that increases overhead. (That's all GC is doing -- deferring collection in order to reduce overhead. Generational GC, for example, is a nice hack where you defer collection of the tenured generation even more in order to improve perf in expected-to-be-common cases.) But if you can't have weak refs, then you have to unbundle the various applications of weak refs and solve them individually (hopefully finding commonalities so you can fix classes of problems at once, of course.) That's why the whole debate gets frustrating -- weak ref proponents understandably feel that if you just had weak refs, you can make a beautiful abstraction that solves a huge class of problems with (rougly) a single mechanism. And therefore, specific examples aren't necessary. But that prevents coming up with any alternative solutions that don't pit the GC against itself. Anyway, with your specific example, it seems to me that the problem is that you're losing information. The popups need the main window to communicate with each other, and the main window needs all of its stuff to work while it's open. The solution, then, seems like it would be to decouple the communication mechanism from the main window. If the object graph representing the communication mechanism were separated out from the rest of the main window, so that there are no outgoing edges from the communication piece to the rest of the main window, then you wouldn't need weak refs. IIUC, the HTML5 spec already has a straightforward way to separate out the communication channels you need -- MessageChannels and MessagePorts [1]. They're not available everywere (anywhere?) yet, but that doesn't mean they aren't the right solution here. I don't know the web platform well enough to suggest something in the absence of those -- is there some way to make the main window a very basic stub and only use it for communication, while putting its current contents in a separate document? Or would you have to fake it by nerfing the window's properties and children when it is closed? [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#channel-messaging _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
