FULL PRODUCT VERSION :


ADDITIONAL OS VERSION INFORMATION :
Solaris 8

A DESCRIPTION OF THE PROBLEM :
The FileChannel.write(ByteBuffer[]) relies on the sun.nio.ch.IOUtil.java write() with an array of ByteBuffer's and if not passed a DirectByteBuffer will allocate shadow buffers on behalf of the application.

Quite innocently we were passing heap allocate byte buffers in a set of three writes. The first two array entries were effectively a long marker, and a long length which were wrapped into ByteBuffers and passed with the payload to FileChannel.write(ByteBuffer[]).

This quite quickly caused out of memory exceptions even though we had sufficiently sized the heap to 1 Gig. The overhead of those 4 Byte DirectBuffers was hurrendous from the C-Heap.

The primarly issue as I see it is the promotion of the running objects into the older generation happened quite quickly with CMS and so we constantly had direct byte buffers being allocated on our behalf and thrown away as garbage.

Wonder if it would have been more efficient for the JDK to have relied on the cached temporary byte buffers and allocated one large enough to hold all of the contents in one byte buffer and then incrementally appended to it?

Alternatively it would have been nice to have forced the memory to be deallocated instead of waiting for the PhantomReference Cleaner to reclaim it.

See another ticket which is related but not the same, marked as Review ID: 348489.


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Avoid FileChannel.write(ByteBuffer[]) or use your own DirectByteBuffers.
###@###.### 2004-12-20 14:42:22 GMT