mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: To keep direct buffer support or not
Date Sun, 10 Dec 2006 03:02:17 GMT
On 12/10/06, Steven Shaw <steshaw@gmail.com> wrote:
> On 08/12/06, Trustin Lee <trustin@gmail.com> wrote:
> http://www.nabble.com/Is-MINA-ByteBuffer-pool-of-dubious-value--tf2652301.html#a7401135
> ),
> > we agreed on removing acquire() / release() methods and pooling
> stuff.  I
> > think it's a great idea, but what do we do now with direct
> buffers?  They
> > take longer to allocate / deallocate, and that was why we introduced
> pooling
> > feature.  Are we just abandoning direct buffers and let users manage the
> > buffer in their own way?
> If you remove direct buffer support how can performance be measured if
> say jdk7 has better direct buffers? What happens when the jdk gets
> some kind of aio? It is likely use direct buffers.

You will still be able to allocate direct buffers.  We're just removing
ByteBuffer pool feature.  If JDK 7 has better direct buffers, users still
can switch to direct buffers.

What do you gain by deleting some existing code? Is that code an
> impediment to other progress? Why not just make the default heap
> allocated ByteBuffers (i.e. no pooling)?

As we discussed in the earlier thread, users have to understand complex
mechanism regarding acquire() and release() because of buffer pooling.  Once
removed, we don't need to worry about pooling at all, and it performs better
with heap buffers.

The problem is that we still have to call acquire() and release() properly
even if we allocated heap buffers because heap buffers are also pooled.
This means pooling support should be optional.  Direct buffers don't perform
any better than heap buffers for now, and nobody's using it.  Therefore, we
could just drop pooling support and wait for JDK 7 (8 or 9 or 10) to have
better direct buffer performance.  There's no reason to add (or retain)
premature pooling support for direct buffers.

Anyway, this is my reasoning behind this thread, but I also want to know
what others think about my idea, to make sure everyone is happy with this
change as a final check, although it is agreed before.

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

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