Sorry, when I say manual cycle-breaking I'm referring to cases where the cycle is kept alive by a root referencing one of the parts of the cycle. The trivial example of this would be an object with event listeners registered on it; if all the references are strong, the object's list of observers keeps the things observing it alive until it dies. Or for the reverse example, if some component is periodically polling the state of an object to see if it has changed, that component is retaining a reference to the object (even if it should be dead). In both of these cases those retained references can then form very large, uncollectable cycles because they have a root. If you 'break' the cycle manually, or prevent it by using weak references, then all the 'effectively dead' objects get collected eventually (with manual cycle breaking, they get collected at a deterministic point in time, but that may be too early or too late.)
It is, however, my understanding that cycle collections in SpiderMonkey are separate from non-cycle-collections and occur less often; is that still true? 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. 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. 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. 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. As Jim points out there are lots of problems that can be solved without using WRs or exposing GC behavior, so it'd be great to figure out whether all the problems causing leaks in JS-implemented DOM objects can be solved without them. Some solutions may implicitly expose GC visibility, at which point they might as well be (in my opinion) weak references; for example most implementations of 'weak observers' that I can think of would implicitly make GC observable and as a result be usable to implement a WeakRef anyway. (Since I've gotten some complaints off-list, to be clear: My reason for responding to this thread initially was to argue with the reasoning 'weak references shouldn't be added to the web platform, so we shouldn't use them'. Since I was involved in extensive discussions re: WRs on es-discuss, I wanted to chime in on that.) -kg On Sun, Mar 23, 2014 at 11:27 PM, Jason Orendorff <[email protected]> wrote: > On 3/22/14, 7:26 AM, K. Gadd wrote: >> 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. > > Kevin, I don't think that's true. Would you please state the desired > behavior for your example, what leaks, and how you would fix it using > weak references? > > It seems like you're under the impression that the JS engine doesn't > collect cycles. It does. > > -j > _______________________________________________ dev-platform mailing list [email protected] https://lists.mozilla.org/listinfo/dev-platform
