With respect, I would disagree with generalizations made from this excerpt in the javadoc. The important reason given in the javadoc is that allocation and freeing of direct buffers are more costly than the trivial cost of allocating a heap buffer. I am confident that this is true in all cases where the garbage collector is not an issue!
> From: Daniel Wirtz [mailto:[EMAIL PROTECTED] > > From the ByteBuffer Java Docs: "It is therefore recommended that direct > buffers be allocated primarily for *large*, *long-lived* buffers that are > subject to the underlying system's native I/O operations." Because of > the small and short-lived nature of buffers inside Mina, I don't see a > reason for using direct buffers at all. Afaik direct buffers make sence > e.g. > for mapping large portions of files on a disk to direct memory for faster > multiple access - I doubt that using them for network packets results in > a performance gain (see also: DirectByteBuffer extends > *MappedByteBuffer*). If we have interest in the hypothesis that copy-avoidance/zero-copy will realize broad server throughput advantages, then it may be more efficient overall to allocate direct buffers, process our bytes, and explicitly free the direct buffers. This removes a possibly heavy burden from the JVM at the cost of risking exhaustion of the memory available to your direct buffers. Direct ByteBuffers have important practical and theoretical considerations for zero-copy reads, gathering writes, and hopefully (tho I haven't looked yet) zero-copy access to MINA APR bindings. I cannot yet confidently say that copy-avoidance/zero-copy in the JVM using heap or direct buffers will ever be a general best solution, but I am keenly interested in testing it. -karl
