이희승 (Trustin Lee) wrote:
On Thu, 22 May 2008 05:14:24 +0900, Emmanuel Lecharny
<[EMAIL PROTECTED]> wrote:
Rich Dougherty wrote:
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).
Pooling objects instead of simple let the GC dispose them is not a
good strategy with modern JVM. With a pool, you introduce a
synchronized structure which will cost more to manage than letting
the JVM creating new objects.
I have played this game years ago, and when switching to Java 5, and
even Java 1.4 to a certain extent, found it a waste of time and
energy ...
Allocating a big direct buffer (say 16MB) once and slicing it into
many pieces for allocation showed very nice performance.
Very nice performance ? In the long term? On complex applications? This
is simply rewriting a GC on your own. Again, I did it once upon a time,
and this is a pretty complex jobs, not worth the effort, IMHO. JVM GCs
are simply too good to spend time to try beating them in this area,
unless you have very specific needs. Alas, MINA is a generic framework :)
The problem is that the current JVM implementation is not good at
handling many big direct buffer allocations - they are not freed when
we need it to be freed. Tomcat native provides a way to explicitly
free direct buffers, so it might resolve the issue.
Anyway, I think we can implement ByteBufferQueue work with both heap
and direct buffers and then think about the side effect of using
direct buffers and discuss what would be the solution?
Yes, that's the best approach : first make it works, then if someone
complains about the performance and exhibit better performance with
Direct buffer, then start to implement another solution.
Seems like we all like the proposed interface anyway. Cool!
Yes, this is quite ok.
Thanks,
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
