Original comment posted by cpovirk+external@google.com on 2009-05-13 at 06:15 PM

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.

Labels: Type-Enhancement

Original comment posted by kevinb9n on 2009-09-17 at 05:52 PM

Issue #236 has been merged into this issue.

CC: crazyboblee

Original comment posted by kevinb9n on 2009-09-17 at 05:53 PM

(No comment entered for this change.)

Original comment posted by kevinb9n on 2009-09-17 at 05:53 PM

(No comment entered for this change.)

Labels: Milestone-Post1.0

Original comment posted by yrfselrahc on 2009-09-18 at 12:26 PM

Issue #236 has been merged into this issue.

Original comment posted by frederic.simon on 2009-09-22 at 12:04 PM

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 posted by yrfselrahc on 2009-09-22 at 01:53 PM

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 posted by frederic.simon on 2009-09-22 at 06:02 PM

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 posted by ian.clarke on 2010-01-29 at 12:12 AM

There is an additional problem with using SoftReferences as a cache, which is that I've
found your memory will fill up with the cached objects, and then the garbage collector
will start to use most of your CPU as it struggles to reclaim RAM before it resorts to
reclaiming the soft referenced objects.

Original comment posted by kevinb@google.com on 2010-07-30 at 03:53 AM

(No comment entered for this change.)

Labels: -Milestone-Post1.0

Original comment posted by yrfselrahc on 2011-01-13 at 07:58 PM

See the new maximumSize method.

Status: Fixed

Original comment posted by plinehan on 2011-01-13 at 09:21 PM

Fantastic! Can we assume this will be in Milestone:Release08?