[concurrency-interest] Memory sensitive memoization

Dhanji R. Prasanna dhanji at gmail.com
Mon Jun 27 03:12:29 EDT 2011


On Mon, Jun 27, 2011 at 4:57 PM, Sanchay Harneja <sanchay.h at gmail.com>wrote:

> > What other behavior could possibly be correct?
> > If you don't know what the key is anymore, you can't tell what value to
> bring back... and it is effectively orphaned.
>
> I would like to think of it this way -
> 1. if keys are hard, but values soft, only values should be
> garbage collectible
> 2. if keys are soft, but values hard, only keys should be garbage
> collectible
>
> Consequences (and side effects) should be understood by the user. For 1. I
> might want the save the key permanently to distinguish the case of [first
> time key] v/s [not first time, but garbage collected].
>

MapMaker (and any library for that matter) have no control over when
something is garbage collected. If you declare a key soft (or weak) it could
disappear at any time, MapMaker cannot expect to have the key sitting around
to call equals() against. If it holds on to the key, then it has hard
referenced it and this amounts to a memory leak.


> On a side note, from my little testing I get the impression that weak refs
> are too aggressively garbage collected, whereas soft refs are only collected
> at the very last moment (effectively crawling the application when memory
> limit is hit).  Both don't work for our application. Think I would need a
> more comprehensive caching strategy.
>

This is the nature of soft references vs weak references. Soft refs are kept
around until the JVM requires more memory (this is somewhat tuneable with a
free memory ratio, so softrefs can be claimed before hitting memory limits).
Your observation is actually the intended, documented behavior.

I would caution against using soft/weak references as an LRU caching
mechanism, having built many Java caches in heavily loaded environments, my
experience tells me that out-of-process caches (like memcached) are
generally better. Others may disagree, of course.

Dhanji.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110627/fb140fb5/attachment.html>


More information about the Concurrency-interest mailing list