softKeys on MapMaker

[Dimitris Andreou]

Hi all,

I think this issue deserves an email, apart from javadoc updates.

How many of you can find usages of softKeys() in your code?

About these usages:

1. Do you rely on SoftReference<K> to keep the keys you want to do lookups in the map?

2. Do you rely on iterating keySet() or entrySet() for discovering K references?

If you answer both negatively, then I think it's fair to say "please treat these softKeys() occurrences as bugs to be fixed". You may want softValues() instead, if you want soft references at all (and not a strong, bounded cache of some sort).

In a nutshell, the issue with softKeys() is this:

For weak/soft keys, to do a successful lookup, you need identity equality, that is, to pass the exact same reference to K you stored in the map in the first place. Which brings up the question, how did you find that K reference? 

1. If you had stored it somewhere in a strong fashion, then having softKeys doesn't make sense - you keep strong references to the keys, so they can't be collected when memory is short.

2. If you had stored them in a WeakReference, then softKeys() doesn't provide you anything more than weakKeys(). As soon as your WeakReferences are cleared, there is no way to access the softKeys(), thus they sit around uselessly (with the exceptions mentioned above).

3. If you had stored them in a SoftReference, then it actually makes sense. As soon as you lose your references, so you can no longer do lookups with them, the entry of the map is released as well. (We would be really, really curious to see if any user actually did this, ever!)

As a reminder, another pitfall using softKeys()/weakKeys() is that it's easy to forget that lookups only succeed via identity match, not equality. This, coupled with a computing map, can cause hard to spot performance bugs, since the computing map always hides the lookup failure (by recreating a value).

Dimitris

[Charles Fry]

Thanks for the nice summary, Dimitris.

One clarification: using softKeys in conjunction with SoftReferences to the keys is the same as using weakKeys with SoftReferences to the keys. The reason is that the key pointed to by the weak + soft reference will be atomically garbage collected, so both will be collected together.

So the real question is: do you use softKeys in conjunction with WeakReferences to the keys? In this case the softKeys are actually causing the keys to stay in memory longer. Of course this case would behave equivalently to weakKeys in conjunction with SoftReferences, so there should be a clear migration path if anyone is relying on this.

Charles

--
guava-...@googlegroups.com
Project site: http://guava-libraries.googlecode.com
This group: http://groups.google.com/group/guava-discuss
 
This list is for general discussion.
To report an issue: http://code.google.com/p/guava-libraries/issues/entry
To get help: http://stackoverflow.com/questions/ask (use the tag "guava")