Outside - Karl's ACM wrote:
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.
This is not eactly what the Javadoc says. The most important sentence is
"...that are subject to the underlying system's native I/O operations".
Ie, use direct buffer for tight integration with some OS managed memory
(graphic memory, any device memory, etc).
Using direct buffer for something else is a kind of violation of this
semantic.
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.
Not only. Allocating direct buffers involve some system calls which may
be very costly, when heap buffers are handled by the JVM without telling
the underlying OS. You may exhaust the system memory, which is
defintively something you want to avoid. The direct memory is the system
memory...
GC cost is generally largely overestimated... I'm doing some Java since
1997, and I have always been told that GC cost a lot, blah, blah, but
everytime I had to check and control some slow application, GC process
was simply not costing more than a few %.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
