mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fedechicco <fedechi...@gmail.com>
Subject Re: ByteBuffer Pool are never refreshed
Date Tue, 21 Feb 2006 16:19:29 GMT
I modded an old 0.8 mina ByteBuffer for a previous app, and in my changes I
track the fewest quantity of byteBuffer in each stack of the pool between
two different times.
In this way I register all over 15minutes the minimum of each stack, and
then at the end of my 15minutes I pop out the byteBuffer unused in that
quarter of hour. (In my  case it was a good change, but you can see that it
was very home-made)

Specifing a max size for the pool is not an easy task because the non-sent
data have to be put somewhere, and limit the memory for the pool means to
limit that somewhere. I think that the way of limit the pool size must be
developed within the overload-prevention part of MINA, because if there is
no more memory we can only stop the producer of the data ( I mean the
SocketIO processor and the IoHandlers ).
Because of this I would not impose a higher limit to the pool, but I would
provide methods to minimize it.

The very last chance to reduce memory usage and buffer allocation time is to
slice big buffers into many little buffers.
The management of a similar pool cannot be a trivial thing, but there are
many nice aspect of a similar method.
In this way we can give gc the smallest buffers, when we have to limit the
memory usage, because we can pretend to have them also if we have only
biggest ones.
Another little nice thing is that we can spend (often) less cpu time in
expanding a buffer: by now in expanding a bytebuffer we have to call from
the pool another buffer and copy all the data, instead with this method we
can choose if to simply enlarge the slice, or to phisically copy in another
buffer all the bytes.

But I think that the mina memory management is already very very good, and
that it don't need this radical changes.

by Fed

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message