The Soft Reference API has been designed to allow java programmers to more precisely handle references to objects so that garbage collection is more efficient and memory is used in a better way.
One can choose to keep only a soft reference to an object instead of a hard one. Thus, the object will be collected if it's absolutely necessary, and will stay around otherwise. This way, for example, a program could keep a reference to an image that has been used but may not be anymore. If the program needs memory, then he image is collected and the soft reference becomes null. If the program needs the picture again later, first it will check whether the soft reference to it still exists. If it does, then the picture is recovered directly. If not, then the picture is reloaded again.
This technique can improve our memory usage in Irf: we wouldn't have to tune our own mechanism to decide when an object should or should not be made lightweight, because the API does it by itself. It implements a LRU or LFU algorithm and we do not have to take care of it. The only thing is to keep only a soft reference to an object when it's not sure it's going to be used again or not.
But which references should be made soft? When? There are several possibilities, most of which have been tested. Here are the results of these tests:
An outOfMemoryError happens during update. This means it doesn't collect well objects that are softly reachable (in addition to putting the reference to the real object to null in makelightweight(), we create a soft reference to the object, so the only difference should be the amount of memory used for those references). No time is saved during indexing.Cause: soft references are not appropriate for ProxyFeatureLists.
Same OutOfMemoryError during update. 30' saved during indexing, not too bad (out of 6 hours).
saved some time during indexing (a few minutes), but update takes a little longer and doesn't seem to work correctly (2 indexes appear to be empty afterwards)
Problem: updates can be lost if softly reachable objects are collected before the changes are written to disk. There is need for a distinction between read-only and read/write methods in the proxies. That's why such a differentiation appears in Ozone, for instance. As only a few methods behave like this currently, it could be possible to make the distinction by hand (adding a call to save()-like methods) but it would decresase performance and is bug-prone.
Again an OutOfMemoryError occured; it looks like there is a bug/incompatibility in the soft reference API, because the current changes should make very little difference in memory usage compared to the regular code (with no soft reference).
It saved a bit more than an hour total but is no part of this test about soft references, the current study just pointed out this problem.