I largely agree with your arguments, but one point is actually more of a counter argument to having weakrefs:
On Mon, Jul 7, 2014 at 10:41 AM, Katelyn Gadd <k...@luminance.org> wrote: > Similarly, it's important to realize that while some use cases for > weakrefs are about managing native resources or doing other 'automatic > cleanup' behaviors, many use cases are simply about ensuring that the > GC can free up large graphs of dead objects *as soon as memory > pressure strikes* instead of waiting until the (likely fragile or > slow) user-space collector gets around to running and collecting > user-space objects. Memory pressure is something the browser and JS VM > have knowledge of that userspace doesn't know about - if a graph is > effectively dead but can't easily have its references cleaned up > automatically (as can happen in complex object layouts, where you > would normally use refcounting or some other mechanism), it's possible > it could remain 'alive' for a long period of time without weakrefs, > eating up valuable heap, moving between GC generations, and slowing > GCs. > While this is true, I think that, as others have argued in the discussion thread I linked to and elsewhere, weakrefs are a bad solution for this. The GC cannot distinguish between different types of resources and their freshness, so they'll just blow away everything they can. In most real-world cases, you'd want to take into account both how frequently and how recently a resource is/was accessed. And, of equal importance, how expensive it is to re-create. You can easily have a large, easily re-created buffer that you'd want to dump at the slightest hint of memory pressure (maybe even to prevent costly GCs from running?), while at the same time you have small-ish objects that are expensive to re-create, so you'd only do so under serious memory pressure. All in all, I think the platform should expose tiered memory pressure notifications, regardless of whether weakrefs are introduced for other reasons.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
