The weak references means the if the object is not referenced by any other objects except the map, it can be GCed. Soft references mean if the heap is limited then the objects in the map may be GCed.
I agree with Noble that I'd rather overshoot the LRU cache size, and let the JVM remove items if for some random reason the cache size is causing OOMs or swapping. At least then my system keeps on running, and I don't need to underestimate my LRU cache size either. On Mon, Oct 19, 2009 at 5:22 PM, Lance Norskog <goks...@gmail.com> wrote: > "Soft references" then. "Weak pointers" is an older term. (They're > "weak" because some bully can steal their candy.) > > On Sun, Oct 18, 2009 at 8:37 PM, Jason Rutherglen > <jason.rutherg...@gmail.com> wrote: >> Lance, >> >> Do you mean soft references? >> >> On Sun, Oct 18, 2009 at 3:59 PM, Lance Norskog <goks...@gmail.com> wrote: >>> -1 for weak references in caching. >>> >>> This makes memory management less deterministic (predictable) and at >>> peak can cause cache-thrashing. In other words, the worst case gets >>> even more worse. When designing a system I want predictability and I >>> want to control the worst case, because system meltdowns are caused by >>> the worst case. Having thousands of small weak references does the >>> opposite. >>> >>> On Sat, Oct 17, 2009 at 2:00 AM, Noble Paul (JIRA) <j...@apache.org> wrote: >>>> >>>> [ >>>> https://issues.apache.org/jira/browse/SOLR-1513?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12766864#action_12766864 >>>> ] >>>> >>>> Noble Paul commented on SOLR-1513: >>>> ---------------------------------- >>>> >>>> bq.Google Collections is already checked in as a dependency of Carrot >>>> clustering. >>>> >>>> in that e need to move it to core. >>>> >>>> Jason . We do not need to remove the original option. We can probably add >>>> an extra parameter say softRef="true" or something. That way , we are not >>>> screwing up anything and perf benefits can be studied separately. >>>> >>>> >>>>> Use Google Collections in ConcurrentLRUCache >>>>> -------------------------------------------- >>>>> >>>>> Key: SOLR-1513 >>>>> URL: https://issues.apache.org/jira/browse/SOLR-1513 >>>>> Project: Solr >>>>> Issue Type: Improvement >>>>> Components: search >>>>> Affects Versions: 1.4 >>>>> Reporter: Jason Rutherglen >>>>> Priority: Minor >>>>> Fix For: 1.5 >>>>> >>>>> Attachments: google-collect-snapshot.jar, SOLR-1513.patch >>>>> >>>>> >>>>> ConcurrentHashMap is used in ConcurrentLRUCache. The Google Colletions >>>>> concurrent map implementation allows for soft values that are great for >>>>> caches that potentially exceed the allocated heap. Though I suppose Solr >>>>> caches usually don't use too much RAM? >>>>> http://code.google.com/p/google-collections/ >>>> >>>> -- >>>> This message is automatically generated by JIRA. >>>> - >>>> You can reply to this email to add a comment to the issue online. >>>> >>>> >>> >>> >>> >>> -- >>> Lance Norskog >>> goks...@gmail.com >>> >> > > > > -- > Lance Norskog > goks...@gmail.com >
