SoftReferences are cleared too eagerlyFeedback from tester:
---------------------

I have noticed an increase in performance with Hotspot!  However, the
garbage collector seems to be a little to aggressive at cleaning up
SoftReferences.   I have not experimented with the other Reference types,
but a Soft Reference is the strongest anyway.


I am implementing a cache and there is a huge difference when running with
HotSpot.  Without it, I get very efficient caching.  With HotSpot I loose my
reference almost right away there by slowing this section of my app
significantly, far below what it was without HotSpot.  (It has to make a
call to a server to get the data that is not cached.)


---
I am using jdk 1.2.1 (with the huge memory leak causing my app to take
anywhere between 20-40MB of memory.  I am running NT4 SP4 on a PII-333 with
128MB of RAM.  I as using the fcs release of HotSpot.


Mark Claassen
Donnell Systems, Inc.
300 S. St Louis Blvd.
South Bend, IN  46617
(219)232-3784
(219)232-4014 (fax)
  xxxxx@xxxxx  





java version "1.2.2"
Java HotSpot(TM) Server VM (2.0rc1, mixed mode, build I)

See Bug #4239645.

Essentially the HotSpotVM is treating a SoftReference just like a
WeakReference, so that any implementation of a cache is rendered useless.
(Review ID: 99113)
======================================================================

N/A

SoftReferences are cleared more eagerly than for classic VM - we should probably move to a similar scheme.

  xxxxx@xxxxx   1999-05-19

We added a LRU policy and stopped immediately clearing soft refs on each gc.

Hotspot seems to make no distinction between 
WeakReferences and SoftReferences as the following
code shows:

import java.lang.ref.*;
import java.util.*;

class R {
	static class Soft {
		protected void finalize() throws Throwable {
			super.finalize();
			System.out.println("soft");
		}
	}
	static class Weak {
		protected void finalize() throws Throwable {
			super.finalize();
			System.out.println("weak");
		}
	}
	public static void main(String[] args) throws Exception {
		ArrayList list = new ArrayList();
		for( int i=0; i<1000; i++ ) {
			list.add(new SoftReference(new Soft()));
			list.add(new WeakReference(new Weak()));
			System.out.println(i);
		}
	}
}

This is a bit annoying.  Moving my servlets from the classic VM to HotSpot
should not result in a slowdown.

Is the bug contained to just HotSpot?  We have two versions 
of the JVM, on of which exhibits the bug, while the other 
does not.  Neither one is HotSpot.

The good version is: java version "1.2.2"
Classic VM (build JDK-1.2.2-001, green threads, sunwjit)

The bad version is: java version "1.2.1"
Solaris VM (build Solaris_JDK_1.2.1_04, native threads, 
sunwjit)

Point being: the bug didn't just crop up in HotSpot.  It 
also existed in other JVMs.  With my two JVMs, I'm not sure 
if the crucial difference is Classic vs Solaris or 1.2.1_04 
vs 1.2.2.  

Cache strategy's that depend on soft references have 
essentially been broken by HotSpot making them next to 
useless.  Please change the algorithm so that soft 
references are only cleared right before you would normally 
throw an OutOfMemoryError, as they are in the classic VM.

Add my name to the list. I'm using SoftReferences for 
caching, and they're getting purged immediately with 
Hotspot. Also, WeakReferences are getting purged 
immediately. This seems incorrect. Memory doesn't appear to 
be tight.

This is not an enhancement issue - it is bloody bug!
My code is dealing with big datasets and it needs
caching to be anywhere near efficient. HotSpot wipes
my carefully prepared caches - written exactly according to
"Sun recommended practice". 

Shall I recommend customers to avoid using HotSpot at 
all?

I am surprised that it is not a high priority bug.
It was there for more then an year - please adjust
the documentation for JDK to reflect that java.lang.ref
package is not operating as described and all
Sun examples on the matter should be ignored.

I ALSO don't understand why this is NOT a TOP PRIORITY BUG... since now that Java
is being touted as a Server platform!!! With the Classic VM SoftReferences are cleared
properly BUT still throws OutOfMemory Exception. With HotSpot SoftReferences behave
like WeakReferences. Hello... how do I use a SoftReference Cache now? You Evaluation
of this bug is also incorrect since it doesn't work with Classic VM also. Can you PLEASE
make this a top Priority bug fix for such a blatant bug!!!

Please add my name to the list of people complaining. We 
are using JDK1.2.2_005. The soft reference seemed to be a 
solution for "running out of memory" problem, but 
apparently is not, as they are eagerly garbage collected. 
What is the use of soft reference as it is implemented now?

-----------more details---------------------------------

We have a cache in our system that holds on to objects, and 
the objects are not bounded in size. If we do not estimate 
the size of the cache properly, then we face the problem of 
"running out of memory". As a result, we have to resort to 
calculation for cache size based on JVM heap memory, but 
that may or may not be applicable to all situations. It is 
ugly. 

Then I read about soft references, which looked like a 
great solution. It allowed us to say, "it will be nice to 
have these objects in cache, but do not do it at the cost 
of running out of memory". With enthusiasm we turned all 
the hard references to soft references. It opened a whole 
new world for us and our system. 

But our initial excitement was short lived. Here are the 
results from our experiment:

1. Suppose I set initial memory to 32MB and max heap size 
to 256MB, then the soft references are garbage collected 
when we need to increase the size beyond 32MB. This is 
pretty bad as we cant have a decent cache. The only work 
around seems to be make the initial size same as max heap 
size. And that is not good as it will hog all the memory as 
soon as we start, and moreover the VM size could be bigger 
than physical memory. Anyway, is there configuration 
setting where we can prevent the soft references from being 
garbage collected when the initial memory limit is reached, 
and it will be garbage collected only when the max heap 
size is reached.

2. I made the initial-heap size same as max-heap and re-run 
the experiment. This time when the max-heap size is 
reached, ALL the soft-references are garbage collected, and 
not "just enough" to allocate new memory. This means our 
entire cache is gone, and we cannot afford to set ALL cache 
references to the soft references. We are now faced with 
choices and making the algorithm more complex: make only 
certain percentage as soft references, and so on.  The 
questions: 

   Is there a way to control what is freed?

While I agree that the SoftReference clearing is too 
aggressive, we should also be cautious about moving too far 
in the other direction. Waiting until the absolute maximum 
heap had been reached before clearing SoftReferences would 
IMHO be too far.
Data which is very expensive to recover should also be 
cached to a (possibly temporary) file. This then places an 
upper bound on the cost of reconstructing an object 
referred to by a SoftReference. Otherwise we would need to 
add a cost attribute to the SoftReference in order to 
support a reasonable strategy. (Note applets should be 
designed to piggy back on the browsers cacheing, or the 
sandbox relaxed to allow access to a temporary file area.)

This is a bug, not an enhancement because the VM is not 
following the spec. I quote from the Package java.lang.ref 

"An object is softly reachable if it is not strongly 
reachable but can be reached by traversing a soft 
reference."

So an object is not softly reachable unless it has no hard 
references!!!!.

And I quote from java.lang.ref.SoftReference

"Suppose that the garbage collector determines at a certain 
point in time that an object is softly reachable. At that 
time it may choose to clear atomically all soft 
references..."

Notice the spec indicates that the garbage collector will 
only clear the soft references if the object is softly 
reachable, i.e. it has no hard references!!!!!

In 1.3 the garbage collector is very agressive, to the 
point that the the Soft references are cleared within 
seconds of being created, even though the object is 
strongly reachable, making soft references usless. 

I vote for this BUG... It is all the more so sad as the 
SoftReference feature is an opportunity for Java to get 
ahead of any language in the memory management area ! 

Indeed, I don't think any other language enables the 
programmer to benefit from an automatic tradeoff between 
memory consumption and CPU time savings... This could be an 
excellent justification (if needed) to port any piece of 
software to Java.

The next step would be to enable SoftReferences to be 
weighed, i.e. less important (as stated by the developper 
through SoftReference instantiation parameters) should be 
cleared before more important references. But that's 
another story !

We really need the SoftReference functionality; a fixed-length LRU
chain won't cut it, since cache items can have great variations in
size, and total cache size cannot be estimated beforehand.  Also, if
this gets fixed, I hope it will clear out the references in LRU order.

I just noticed that you fixed this against a non-public 
release. Any idea when this release will become public, or 
what public version this bug fix is targeted for??

ramaiyerk, 

here's some interesting info I just found out. Presumably 
this will apply to the next release of Hotspot, 2.0 / 1.3.0 
Client VM has this bug which will prevent this working.

"Hotspot Server prefers to grow heap size.  It will 
generally defer collection of SoftReferenced Objects if it 
has room to grow the heap. For this reason -Xmx has a big 
effect on when SR's get collected.  The larger  -Xmx, the 
less likely it is you will flush SR's from memory.  -Xms 
though has no appreciable effect.

Hotspot Client though is different.  It generally tries to 
avoid growing the heap and instead prefers to clear SR's.  
For this reason it generally will not grow the heap before 
it flushes SR's from memory.  Therefor -Xms has a large 
effect, the bigger you make the default heap, the longer 
the SR's stick around."

Looks like the Win32 -classic VM works like the HotSpot 
client VM.

Gee I wish this was documented!!!

Hope this helps.

It is VERY important to note that the behavior of 
SoftRefrences in Hotspot noted above is undocumented 
behavior.  Its is therefor is **not** garuanteed to remain 
this way from version to version.

In general for any information, if its not in the spec, you 
cannot count on it
always being true.

"In general for any information, if its not in the spec, 
you cannot count on it always being true."

Unfortunately, the converse is not true.  Just because 
something is documented in the spec, does not mean it works 
correctly.  This flaw in Hotspot clearly contradicts the 
documentation in SoftReference.  When will the "non-public 
release" be made available?  Until then, a lot of 
developers are left high and dry.  

For anyone who cares, it appears that this has been fixed 
in the 1.3.1-beta that is posted on the developer center 
early access downloads.

It appears that this bug was not fixed in 1.3.1b cause i 
have this problem with it same as 1.3.0

I am afraid this *big* issue is not solve with JDK 1.3 for 
Solaris 2.8: once we get many simultaneous users on our web 
site, our SoftReferences cache entries are emptied in the 
second they are allocated!

Win32 1.3 both client (Java HotSpot(TM) Client VM (build 
1.3.0-C, mixed mode)) and server (Java HotSpot(TM) Server 
VM (build 2.0fcs-E, mixed mode)) have this same problem, 
very dissapointing...