Hello karl,
> 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. However I think that this burden was taken into account when the JVM was designed. When removing this burden, we should use C instead. All we can do is move the memory allocation from the JVM to pure Java. The performance impact may be hypotetical comparably that of imlementing the TCP/IP stack in pure Java. > 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. Yes they have, but only if there is a way to pass some memory contents from one to another application (or the OS). To take advantage of this, we may need to hack the JVM and maybe the OS's network implementation I think. Let's say we socket.read(buffer) something. The contents will be inserted into a buffer that we allocated before so it is absolutely indifferent what type this buffer is of because it was not passed untouched by the network interface (or the OS) to the JVM. The same happens for writing buffers - the buffer must exist as some sort of memory and is then written through the JVM to the OS's network implementation. Of course it may be copied by one network implementation but not by another one - we don't know and we cannot affect it anyhow after the contents have been written out. I think the discussion spaces out a little. The zero-copy approach is mostly about elimination the overhead of ByteBuffer.setAutoExpand(true) that copies the whole buffer to resize it - and this is bad because it may happen very often depending on the particular implementation of a protocol or a whole application. Another advantage is that a queue may be reused to eliminate the need to buffer the contents (as a copy) e.g. inside the protocol decoder - with queues mina can do this for the protocol zero-copy. By extending the previous bytebuffer approach, there are some nice performance benefits but we should not lose the target so early ;) regards Daniel
