On 11/03/2013 08:16 AM, Brendan Eich wrote: > Bobby Holley wrote: >> This won't solve esoteric cross-vat use cases, but I think it would be a >> nice way to bulldoze the subtle gotchas that make it so easy to introduce >> subtle leaks in large-scale JS. > > With an MVC framework, nukeSandbox is of no avail. The subject does not > want to extend the lifetime of the object it observes, but it need not > be notified exactly when that object "becomes garbage" semantically. It > could be at a later event turn -- just not so late that garbage piles > too high. > > This suggests a solution, which I thought was standard in GCs with weak > refs (but I'm rusty): tenure any weak referent as soon as it is know to > be such (even if it might not be weakly referred to for its entire > lifetime). Let people buy trouble by the yard (or more, if they tie > combinatorially explosive knots) until the tenured generation is big > enough that a full M&S GC must be done.
This is exactly what we do. > Anyway, that's the theory (modulo bugs in my memory) and IIRC it > suffices for weak maps, which we already implement. Are weak refs any > worse (as Igor asks, are they not "better" by some measures)? I explicitly aliased all weak primitives (weakrefs, weakmaps with weak values, weakmaps with strong values, etc) in my discussion. The issues here are unbelievably subtle and complex: I think it is extremely difficult to say "hard" or "easy" without looking at the specifics of both the proposal and the GC and then spending a day just thinking about the potential pitfalls (or just implementing and fuzzing it). While, in general, weak refs are categorically less complicated -- and I do think that holds for our current GC -- I would want to spend some time thinking about the combination of weakrefs + JS weakmaps + future GC plans before commenting. > /be > _______________________________________________ > dev-tech-js-engine-internals mailing list > dev-tech-js-engine-internals@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals _______________________________________________ dev-tech-js-engine-internals mailing list dev-tech-js-engine-internals@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-js-engine-internals
