[concurrency-interest] Memory sensitive memoization

Sanchay Harneja sanchay.h at gmail.com
Mon Jun 27 04:25:41 EDT 2011


Hi Dhanji,

The trouble point is, if I declare a key hard, it still disappears (if value
is declared soft); which might be fine depending on one's perspective.

Thanks for pointing me towards softrefs tuneable parameter!  I'll give it a
shot. But ultimately, I might go towards something like memcached, as you
suggest.

Regards,
Sanchay

On Mon, Jun 27, 2011 at 12:42 PM, Dhanji R. Prasanna <dhanji at gmail.com>wrote:

>
>
> 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/4465eea0/attachment.html>


More information about the Concurrency-interest mailing list