MapMaker to create a bounded cache (similar to LRU)

[GoogleCodeExporter]

This is not a defect but the "template" options did not have any way to
report an enhancement request.

It would be nice if the MapMaker had additional ways to expire entries
other than a time duration.  Specifically, LRU/MRU would be very useful if
I want to use the Map as a cache but only for a limited number of entries.

Original issue reported on code.google.com by kevin.a....@gmail.com on 13 May 2009 at 6:04

[GoogleCodeExporter]

This same issue has come up internally, and we're looking into it.

Note that sometimes using soft references for keys/values is an option, since 
the GC
may be strategic about which references it clears.  This has drawbacks, of 
course: 
You might have two caches, one with infrequently accessed but 
expensive-to-compute
values and one with frequently accessed but cheap-to-compute values.  The fact 
that
the elements in the latter are globally more frequently used than those of the 
former
doesn't mean that you want to elements of the former thrown out.

Marking as "enhancement," as requested.

Original comment by cpov...@google.com on 13 May 2009 at 6:15

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Issue 236 has been merged into this issue.

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:52

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:53

• Changed title: MapMaker to create a bounded cache (similar to LRU)

[GoogleCodeExporter]

Original comment by kevin...@gmail.com on 17 Sep 2009 at 5:53

• Added labels: Milestone-Post1.0

[GoogleCodeExporter]

Issue 236 has been merged into this issue.

Original comment by yrfselrahc@gmail.com on 18 Sep 2009 at 12:26

[GoogleCodeExporter]

I agree with the need of a 2-level cache: Hard ref LRU/MRU bounded, then the 
rest on
Soft References for using the available resources.
I personally saw too many system crashing with OOME because of too big LRU, and 
other
not using any of the heap size available.
Full soft references is not a good solution, since when memory crisis arrive 
deleting
all the SoftReferences is a sure way to disaster. The system will need even 
more heap
to fill up the heavily used objects.
I know you'll find the perfect solution :)

Original comment by frederic...@gmail.com on 22 Sep 2009 at 12:04

[GoogleCodeExporter]

Actually soft references are collected in an LRU fashion (per their Javadoc), 
so it sounds like you can already get 
what you want with MapMaker...

Original comment by yrfselrahc@gmail.com on 22 Sep 2009 at 1:53

[GoogleCodeExporter]

It's true, but I found 2 issues with a full soft references cache system:
1. LRU is global for ALL soft references in the VM. Some specific cache are more
important and sometimes less accessed than other.
2. The actual size/time to build of the object is ignored. It's more related to 
LRU
but in most cases the size/cost can be associated with a specific cache, so 
back to
point 1.

BTW: I use MapMaker with SoftReference for all caches + EhCache for hard ref on 
the
critical caches. I can do better, but for now it works and stable.

I'll really preferred a All-in-one solution.

Original comment by frederic...@gmail.com on 22 Sep 2009 at 6:02

[GoogleCodeExporter]

This issue has been moved to the Guava project (keeping the same id number). 
Simply replace 'google-collections' with 'guava-libraries' in your address 
bar and it should take you there.

Original comment by kevinb@google.com on 5 Jan 2010 at 11:09

• Changed state: Moved