You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Thomas Vinod Johnson (JIRA)" <ji...@apache.org> on 2007/07/27 16:30:18 UTC
[jira] Created: (RIVER-102) (mux) optimize allocation/deallocation
of direct buffers
(mux) optimize allocation/deallocation of direct buffers
--------------------------------------------------------
Key: RIVER-102
URL: https://issues.apache.org/jira/browse/RIVER-102
Project: River
Issue Type: Improvement
Components: net_jini_jeri
Reporter: Thomas Vinod Johnson
Priority: Minor
Bugtraq ID [6304047|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6304047]
Profiling of JERI performance tests configured to use net.jini.jeri.tcp endpoints on an 8-way multiprocessor has shown allocation (and implicit deallocation) of direct buffers to be a major bottleneck.
Consider optimizations like pooling of direct buffers that we allocate, but also consider the effects of direct buffers created by the underlying J2SE implementation. For example, it seems that the implementation of GatheringByteChannel.write on a SocketChannel allocates a new temporary direct buffer for each non-direct buffers passed to it, like all the 4-byte non-direct buffers that will be used for message headers. Also, it appears that a direct buffer allocation is occurring per iteration of the select loop, which seems undesirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (RIVER-102) (mux) optimize
allocation/deallocation of direct buffers
Posted by "ukong.wong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12517990 ]
ukong.wong commented on RIVER-102:
----------------------------------
I am just a casual user of MINA but I come across looking at the source code of PooledByteBufferAllocator when I found out that my app has been using a lot non-heap memory which does not seem to release.
I believe direct buffers are not garbaged collected but in the current implementation of PooledByteBufferAllocator, the stacks of direct buffers are expired the same as heap buffers (in class PooledByteBufferAllocator.Expirer, around line 260)
As long as direct buffers are not garbaged collected, would it be better NOT to expire direct buffers - always keep their references and reuse them?
If direct buffers WERE released to the OS, I bet it wouldn't happen very frequently - therefore current default of 60 seconds of timeout for direct buffer does not look reasonable.
> (mux) optimize allocation/deallocation of direct buffers
> --------------------------------------------------------
>
> Key: RIVER-102
> URL: https://issues.apache.org/jira/browse/RIVER-102
> Project: River
> Issue Type: Improvement
> Components: net_jini_jeri
> Reporter: Thomas Vinod Johnson
> Priority: Minor
>
> Bugtraq ID [6304047|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6304047]
> Profiling of JERI performance tests configured to use net.jini.jeri.tcp endpoints on an 8-way multiprocessor has shown allocation (and implicit deallocation) of direct buffers to be a major bottleneck.
> Consider optimizations like pooling of direct buffers that we allocate, but also consider the effects of direct buffers created by the underlying J2SE implementation. For example, it seems that the implementation of GatheringByteChannel.write on a SocketChannel allocates a new temporary direct buffer for each non-direct buffers passed to it, like all the 4-byte non-direct buffers that will be used for message headers. Also, it appears that a direct buffer allocation is occurring per iteration of the select loop, which seems undesirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (RIVER-102) (mux) optimize allocation/deallocation
of direct buffers
Posted by "ukong.wong (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
ukong.wong updated RIVER-102:
-----------------------------
Comment: was deleted
> (mux) optimize allocation/deallocation of direct buffers
> --------------------------------------------------------
>
> Key: RIVER-102
> URL: https://issues.apache.org/jira/browse/RIVER-102
> Project: River
> Issue Type: Improvement
> Components: net_jini_jeri
> Reporter: Thomas Vinod Johnson
> Priority: Minor
>
> Bugtraq ID [6304047|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6304047]
> Profiling of JERI performance tests configured to use net.jini.jeri.tcp endpoints on an 8-way multiprocessor has shown allocation (and implicit deallocation) of direct buffers to be a major bottleneck.
> Consider optimizations like pooling of direct buffers that we allocate, but also consider the effects of direct buffers created by the underlying J2SE implementation. For example, it seems that the implementation of GatheringByteChannel.write on a SocketChannel allocates a new temporary direct buffer for each non-direct buffers passed to it, like all the 4-byte non-direct buffers that will be used for message headers. Also, it appears that a direct buffer allocation is occurring per iteration of the select loop, which seems undesirable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.