mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steven Shaw" <stes...@gmail.com>
Subject Re: To keep direct buffer support or not
Date Sun, 10 Dec 2006 14:34:16 GMT
On 10/12/06, Trustin Lee <trustin@gmail.com> wrote:
> 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.

Direct buffers won't be much good without 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.

Then it was probably my misunderstanding. I figured that MINA did the
appropriate acquire() and release() under the hood. Perhaps it was
just in a subset of cases. I figure that if you strip out all the
calls to acquire() and release() from MINA, then anyone wanting to use
pooled direct buffers in the future will certainly have to find the
appropriate places for acquire() and release() in their _user_ code.

> 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.

Perhaps that right. I certainly don't think pooled heap buffers should
be the default! Pooling should be optional.


View raw message