Hi Daniel

Although MINA probably *uses* buffers for short periods of time, wouldn't it
be possible to make the underlying buffers "long-lived" by pooling them
between usages? Of course, if we pooled buffers then we'd need to support
some mechanism of returning the buffers to the pool (probably an explicit *
free* or *dispose* operation).

To me, the question of whether or not its worth the bother of doing this
comes down to the following questions:
- is there any performance benefit of using direct buffers?
- is it feasible for users to manually dispose each buffer or slice that
they use *or* can we do this automatically for them somehow?

Cheers
Rich

On Thu, May 22, 2008 at 1:08 AM, Daniel Wirtz <[EMAIL PROTECTED]> wrote:

> 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*).
>
> However, I played around a bit with direct and heap buffers, testing some
> possible cases that could lead to unexpected behaviour, but everything
> worked fine with direct buffers, too, so there should be no problem. Direct
> buffers support duplicate(), position(), limit(), all the
> setters/getters and they have their own custom dealocator that will hook
> the
> direct byte array to the wrapping directbytebuffer instance or even
> multiple
> instances for duplicates (
>
> http://dmi.ensica.fr/doc/Java/j2sdk-1_4_2-doc/docs/j2h/java/nio/DirectByteBuffer.java.html
> )
> so this should basically work the same like gcing heap buffers. The
> implementation seems to be mostly the same, just the underlying byte array
> is "directly mapped".
>
> Feel free to correct me if I'm wrong.
>
> regards
> Daniel
>

Reply via email to