Soft references (java.lang.ref.SoftReference) and the memory-advice API upon
which they are based (java.lang.Runtime.MemoryAdvice etc.) have proven to be
unworkable in their present form. Soft references are not always cleared in
time to prevent OutOfMemoryErrors from being thrown. They are also not cleared
as aggressively as they are by the 1.1 VM, thereby contributing to the
memory-footprint bloat we're seeing with 1.2.
The problems with soft references are due largely to the fact that they are
implemented atop the memory-advice API, which is fundamentally incapable of
ensuring the close cooperation between the garbage collector and Java-level
cleanup threads that is necessary to implement memory-sensitive structures such
as soft references. A better way to implement soft references is to wire them
directly into the GC, just like the other reference-object types.
Finally, further discussion of the SoftReference class itself has led to a
revised specification that, unlike the present specification, clearly describes
what is and is not guaranteed and can therefore be used as the basis of an
effective JCK test.
-- mr@eng 4/16/1998
which they are based (java.lang.Runtime.MemoryAdvice etc.) have proven to be
unworkable in their present form. Soft references are not always cleared in
time to prevent OutOfMemoryErrors from being thrown. They are also not cleared
as aggressively as they are by the 1.1 VM, thereby contributing to the
memory-footprint bloat we're seeing with 1.2.
The problems with soft references are due largely to the fact that they are
implemented atop the memory-advice API, which is fundamentally incapable of
ensuring the close cooperation between the garbage collector and Java-level
cleanup threads that is necessary to implement memory-sensitive structures such
as soft references. A better way to implement soft references is to wire them
directly into the GC, just like the other reference-object types.
Finally, further discussion of the SoftReference class itself has led to a
revised specification that, unlike the present specification, clearly describes
what is and is not guaranteed and can therefore be used as the basis of an
effective JCK test.
-- mr@eng 4/16/1998
- duplicates
-
JDK-4124447 (gc) The GC needs to be more aggressive in discarding soft refs
-
- Closed
-
-
JDK-4213830 LowMemoryListener for Garbage Collector
-
- Closed
-
- relates to
-
JDK-4593108 Detect low memory conditions and recover
-
- Closed
-
-
JDK-4140301 (gc) JVM lacks mechanism for responding to low system memory conditions
-
- Closed
-
-
JDK-4132659 (gc) Bug in original gc.c allocation barrier mechanism
-
- Closed
-