4

I read this article and now I'm clear about what is the basic difference between weak and soft references. I also understand that unlike weak references (which will cause the object to be collected in the next GC cycle if no strong references are there to that object), soft references are kept in memory until JVM runs out of memory.

But the question I have is if JVM runs out of memory and Garbage Collector starts collecting the soft references also, it should logically collect all the existing objects with soft references (my guess). Am I right about this?

Another thing that comes to my mind is that soft references have a very good use case, that is in-memory caches. But if all the soft references that I have will all be cleared in one single shot by GC, then it may not be the expected thing that we always want.

Is there a way to control the percent of soft-references that will be cleared? Or can we tell the GC to stop clearing the soft-references once it has recovered some specific amount of memory?

I'm asking this for the sake of getting a good grip on how soft references can be used effectively, and obviously no one will want their cache to be completely evicted from memory even when you need a very small amount of memory.

Lavish Kothari
  • 2,211
  • 21
  • 29
  • *"it should logically collect all the existing objects"* Yes it should, normally, but as Ghost Cat answered below there are reasons why the exact garbage collection algorithm is not specified, and the JVM could decide to do almost anything at all. Best to not assume any specific behavior. But as a conceptual mental model, yes you can assume that usually a full GC will collect all soft and weak references, maybe not *exactly* at the same time, but around the same general time. – markspace Aug 12 '18 at 20:33
  • To give a little more example, there's a long list of options for the garbage collector for Java 10. It's really up to the user who runs your program what the garbage collector does, and in the future you can expect even more options. https://docs.oracle.com/javase/10/tools/java.htm#GUID-3B1CE181-CD30-4178-9602-230B800D4FAE__BABFAFAE – markspace Aug 12 '18 at 20:39

1 Answers1

3

More of an informal answer here:

First of all, it is not necessary logical to collect all soft references immediately. Theoretically, the JVM could (additionally) track last usage, or some usage counter. And make decisions based on that (to first clear only soft references that are "older" or "less used"). Or it orders soft references by the actual amount of memory the reference "links" to.

Beyond that, the JVM might operate on fixed memory increments. Meaning: why throw out soft references for 500 MB of memory, when you only need/want 50 MB?!

In other words: clearing all soft references is simple the "most easy to implement" strategy, but not necessary the only option. A JVM could be free to implement all sorts of strategies. For example one that tries to remove as few soft references as possible, in order to specifically support in-memory caches!

So unless some other answer can show the JLS section that clearly states that they should all be cleared in one shot, you should not drive conclusions based on your "perception" of what is logical.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
  • In case of HotSpot/OpenJDK, it *does* track the usage. Estimating the amount of memory that clearing a particular soft reference would release, would be a really great thing, but I doubt that any implementation tries this, as it is way too expensive to calculate. – Holger Aug 13 '18 at 14:43
  • @GhostCat I got that unless it's mentioned in some JLS topic, it is wrong to assume that JVM implements the simplest available option. But I'm still wondering if there is any way by which we can tell the JVM to go for a smart approach so that I can be sure that soft-references are not evicted in one single shot (which *might* be the case) – Lavish Kothari Aug 14 '18 at 17:51
  • I think you can't hope for more than that comment from markspace you received yesterday. – GhostCat Aug 14 '18 at 18:11