You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "ukong.wong (JIRA)" <ji...@apache.org> on 2007/08/06 19:39:59 UTC

[jira] Updated: (RIVER-102) (mux) optimize allocation/deallocation of direct buffers

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