Details
-
Improvement
-
Status: Open
-
Minor
-
Resolution: Unresolved
-
None
-
None
-
None
-
6304047
Description
Bugtraq 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.
Attachments
Issue Links
- is related to
-
RIVER-318 JERI Performance Issues
- Open