[ http://issues.apache.org/jira/browse/DIRMINA-62?page=all ] Mark Atwell closed DIRMINA-62: ------------------------------
> Memory 'Leak' when causing auto-expandable ByteBuffer to expand and change > buffer-pool (stack). > ----------------------------------------------------------------------------------------------- > > Key: DIRMINA-62 > URL: http://issues.apache.org/jira/browse/DIRMINA-62 > Project: Directory MINA > Type: Bug > Versions: 0.7.2 > Environment: Non-specific. > Reporter: Mark Atwell > Assignee: Trustin Lee > Fix For: 0.7.3 > > We have been using the excellent MINA library - BTW how do you pronounce > this: Minner? or Minor? or...? > Anyway, we had an apparent memory leak when using the MINA code with > auto-expandable ByteBuffers. > I've tracked it down to the allocate/de-allocate algorithm and buffering. > The problem is that we originally requested a small initial buffer and then > putXXX() tons of things into it, causing it to grow. However, when the buffer > is released (implicitly by calling ...write), the now large buffer gets > released to a different pool (stack). Since these are unbounded, pools, the > large-buffer pool just aggregates the big buffers - which practically never > get used. > I originally thought that I could just release the underlying ByteBuffer when > the pool reaches some maximum, but no joy. It looks like I may need to rely > on garbage-collection kicking in, but this is far from effective (For > JavaSoft's Lame 'solution', see: > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4879883 ). Why can't the > NIO class have a deallocate/release call?! Grrrr! :o( > I believe a better/more elegant solution may be to modify > ByteBuffer.ensureCapacity() to also use the stack/pools rather than allocate > more native ByteBuffers... and I guess that this would be faster also? I've > tested this and it seems to work fine: > The change is in ByteBuffer.ensureCapacity. Change: > java.nio.ByteBuffer newBuf = isDirect() ? > java.nio.ByteBuffer.allocateDirect(newCapacity) : > java.nio.ByteBuffer.allocate(newCapacity); > To: > java.nio.ByteBuffer newBuf = allocate0(newCapacity,isDirect()); > Obviously one of the things one can do in the interim is work out (or > approximate/over-estimate) the maximum buffer size, but if we want to do this > with any degree of accuracy we need to encode our buffer first, which rather > defeats the purpose/benefit of the ByteBuffer. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
