$ /disk0/j2sdkee1.4.0-rc/j2sdk1.4.0/bin/java -version
java version "1.4.0-rc"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-rc-b91)
Java HotSpot(TM) Client VM (build 1.4.0-rc-b91, mixed mode)

SocketChannel.read/write(dsts, offset, length) leaks memory. The attached
test leaks up to 300K per second on my U10/440 when performing
scattering reads. Gathering writes also leak. Using the single buffer
version of the read and write methods does not appear to leak.

The test consists of a simple client and server. The client establishes
a socket connection to the server and writes data to the server.
The server reads the data.

The test provides various command line options to control how the
IO is performed. Use -help to see what they are.

By default the client and server use single buffer versions of
the methods and no leaking occurs. But if you run the server with
the "-scatter" option you will see the process size grow steadily.
To reproduce run

$/usr/java1.4/bin/java -cp . PacketTest -server -scatter

$/usr/java1.4/bin/java -cp . PacketTest -client

Inspect the process size using 'ps -o vsz -p <pid>' and you will see
that the server process grows steadily while the client does not.
If you run the client with the "-gather" option you will see that
it grows as well.

The test program also supports "-stats" which periodically
dumps VM memory statistics that show that the Java heap is not
growing.

If you run 'pmap' on the growing process you will see that it is
the malloc heap that is growing.

I have only tried this on Solaris 8.