I think the JVM's distinction between *soft* and *weak* references is relevant here. A soft reference is basically a weak reference, but the user requests that the GC not throw away the soft reference unless memory is tight:
http://docs.oracle.com/javase/7/docs/api/java/lang/ref/SoftReference.html It is explicitly intended for caching. Niko On Tue, Dec 17, 2013 at 04:49:40PM +0100, Till Schneidereit wrote: > On Tue, Dec 17, 2013 at 4:43 PM, Jason Orendorff > <jorendo...@mozilla.com>wrote: > > > On 12/17/13 8:37 AM, Till Schneidereit wrote: > > > Here's another use case for weak references that I don't think has been > > > mentioned yet: > > > > > > Caching of expensive-to-recreate data. > > > > If you actually did this, you would soon want some control over the > > cache: the ability to retain recently used entries across GC, for > > example; the ability to treat some caches as more important than others; > > etc. > > > > To add to Andrew's point, while the data binding use case supposedly > > needs weak references to be freed as soon as possible, this use case > > requires the opposite: weak references that stick around as long as > > possible. > > > > This is another anti-use-case for weak references: an intuitively > > appealing use that turns out to be worthless in practice. > > > > > I actually did use this, and disagree. While I think that what Andrew > proposed is better, having weak references is still better than having > nothing at all. However, low-memory events are probably not only better, > but also far less controversial, so yes: as a real argument for weak > references, this is moot. > _______________________________________________ > 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
