FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Solaris 8

A DESCRIPTION OF THE PROBLEM :
In JDK 1.4.2_05 the releaseTemporaryDirectBuffer() was modified to avoid replacement of smaller DirectByteBuffers but that was re-added in JDK 1.4.2_06 and is present for the JDK 1.5.0 and JDK 1.6.0 source trees.

While I understand the advantage, I don't believe it fully takes care of potential memory issues off the C-Heap as the SoftReference is to my understanding within the scope of the Java Heap garbage collection entirely independent of the C-Heap. Thus, the very small SoftReference will in general hold a larger C-Heap reference to physical memory and while the java.nio.Bits.java reserveMemory() request will attempt a System.gc() on low C-Heap space, it is highly probable that the JVM GC will not be low on Java Heap memory and thus not release the SoftReferences in the Threads holding the DirectByteBuffer allocations.

With the present configuration, once a large buffer has been allocated in a thread it is unlikely to ever disappear if the Java Heap is appropriately sized and there are a number of threads holding large buffers as the SoftRerence doesn't need to be cleaned up necessarily.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
OutOfMemoryError

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Managing the way the application handles threads and direct byte buffers this can be worked around.
###@###.### 2004-12-20 13:19:41 GMT