[concurrency-interest] Memory sensitive memoization

Sanchay Harneja sanchay.h at gmail.com
Mon Jun 27 02:57:12 EDT 2011


> 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].

But the current behavior offered by guava is ok too. In fact I'm using,
(hopefully correctly), softValues() as a substitute for soft keys + key
comparison using .equals.

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.

Thanks!
Sanchay


On Mon, Jun 27, 2011 at 11:10 AM, Dhanji R. Prasanna <dhanji at gmail.com>wrote:

>
>
> On Mon, Jun 27, 2011 at 2:17 AM, Sanchay Harneja <sanchay.h at gmail.com>wrote:
>
>> Hi Bob,
>>
>> Indeed, MapMaker's javadoc says:
>>
>> If strong or weak references were requested, it is possible for a key or
>> value present in the the map to be reclaimed by the garbage collector. If
>> this happens, the entry automatically disappears from the map.
>>
>> But I find this somewhat counter intuitive.
>>
>
> 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.
>
> Dhanji.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20110627/5497da3b/attachment.html>


More information about the Concurrency-interest mailing list