FULL PRODUCT VERSION :
java version "1.4.2_06"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_06-b03)
Java HotSpot(TM) Client VM (build 1.4.2_06-b03, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
 customer  Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
This problem is similar to that reported in 4405807. When I have a subclass of ObjectOutputStream or ObjectInputStream loaded through a ClassLoader that is later thrown away, the SoftCache in field subclassAudits of both ObjectInputStream and ObjectOutputStream won't let go of the Class  customer  for the stream subclass, and subsequently the ClassLoader that loaded it. The system runs out of memory on few occurrences of reloading the stream subclass through new ClassLoader-s.

In very rare circumstances the class and the class loader will be released, but for this to happen both conditions below must be satisfied:
a) low enough level of free memory so that soft references are cleared
b) but still high enough memory level so that next time code is reloaded and the subclass of ObjectOutputStream initialized, the SoftCache.processQueue() runs without running into OutOfMemoryError first.

A solution to the problem would be to replace the SoftCache with a WeakHashMap. I'd also recommend you revisit the use of the SoftCache across all the JDK code, as together with 4405807, this is at least the second case of it causing trouble.

I just checked, and 1.5.0 source code for ObjectOutputStream still uses SoftCache.


REPRODUCIBILITY :
This bug can be reproduced always.
  xxxxx@xxxxx   2005-2-23 05:20:54 GMT

N/A

must be fixed in mustang
  xxxxx@xxxxx   2005-04-14 19:01:43 GMT

Here's the contents of an update e-mail I sent to Sun and that's not yet reflected in this bug report page:

"In the meanwhile, I discovered that replacing ObjectInputStream.subclassAudits and ObjectOutputStream.subclassAudits SoftCache objects 
with WeakHashMap objects alone won't fix the problem. There are two other SoftCache objects used by serialization that will also retain 
the class loaders longer than desired and therefore cause the system to run out of memory: ObjectStreamClass.localDescs and 
ObjectStreamClass.reflectors. They should also be replaced with WeakHashMaps." -- Attila

Its a shame the 1.5.0.7 release didnt fix this problem in the Thread class aswell.

I create classloaders adhoc and these temporary classes can create threads which cause Thread.subclassAudits to retain references to my temporary classloaders.

Parwy Sekhon