On 3/24/14, 2:42 AM, K. Gadd wrote: > It is, however, my understanding that cycle collections in > SpiderMonkey are separate from non-cycle-collections and occur less > often; is that still true?
There are two collectors. The JS engine's garbage collector runs more frequently. It collects cycles among ordinary JS objects, functions, arrays, that sort of thing. The XPCOM cycle collector runs less often. It is only required to collect cycles that involve reference-counted C++ objects — which includes DOM nodes. So, oddly enough, self-hosting the DOM would mean that your cycles would be collected *sooner*. > My example was merely intended to demonstrate a case where you can > easily end up with a scenario where manual cycle-breaking has to > happen, not something that absolutely is unsolvable without WRs. I am starting to think the problem as posed can't be solved using weak references. A few solutions not involving weak references have been suggested. (I still like Jim's formula: "identify the points at which an observer becomes useless". Someone should write that library.) > If > the browser is clever about using WRs internally for references to > windows, or between windows, then less objects stay alive longer than > they're supposed to. We use revocable proxies for references between windows, and in some cases we will mass-revoke all proxies pointing into a particular window, and blow that whole window out the air lock. That's not the same thing as weak references. In fact weak references would not help you implement it, even though the user-visible behavior seems similar (stuff nondeterministically vanishes). The decision of when to kill a window is not made by the garbage collector. It's a totally different heuristic, one that takes into account that we really *don't* want windows to be dropped as soon as the GC runs. (See Jim's post quoting Allen quoting George Bosworth on heuristics.) Details of garbage collection are not exposed to user code. Finalization is not observable. > If you move everything entirely into > user-authored JS, various problems get harder because now you can't > rely on the C++ parts of the browser to break cycles for you. Revocable proxies are in ES6. > The > canonical example I used in some es-discuss threads is the idea of an > 'application' that hosts multiple isolated 'modes', where the modes > can reference each other and the application references all active > modes. In such an application, it becomes trivial for a single active > mode to hold references to dozens of dead modes, as a result leaking > *all* of them until the cycle is manually broken or all modes are > closed. I do love examples, but maybe we can get to the second example after the first one is well understood. -j _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
