[ https://issues.apache.org/jira/browse/HBASE-14490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15143877#comment-15143877 ]
Elliott Clark commented on HBASE-14490: --------------------------------------- Unless there is a noticeable benefit, is there a reason to try and defeat the GC? Short lived objects are very very cheap with newer jvm's and adding complexity that would be disabled for people running a newer jvm seems weird. > [RpcServer] reuse request read buffer > ------------------------------------- > > Key: HBASE-14490 > URL: https://issues.apache.org/jira/browse/HBASE-14490 > Project: HBase > Issue Type: Improvement > Components: IPC/RPC > Affects Versions: 2.0.0, 1.0.2 > Reporter: Zephyr Guo > Assignee: Zephyr Guo > Labels: performance > Fix For: 2.0.0, 1.0.2 > > Attachments: 14490.hack.to.1.2.patch, ByteBufferPool.java, > HBASE-14490-v1.patch, HBASE-14490-v10.patch, HBASE-14490-v11.patch, > HBASE-14490-v12.patch, HBASE-14490-v2.patch, HBASE-14490-v3.patch, > HBASE-14490-v4.patch, HBASE-14490-v5.patch, HBASE-14490-v6.patch, > HBASE-14490-v7.patch, HBASE-14490-v8.patch, HBASE-14490-v9.patch, gc.png, > hits.png, test-v12-patch > > > Reusing buffer to read request.It's not necessary to every request free > buffer.The idea of optimization is to reduce the times that allocate > ByteBuffer. > *Modification* > 1. {{saslReadAndProcess}} ,{{processOneRpc}}, {{processUnwrappedData}}, > {{processConnectionHeader}} accept a ByteBuffer instead of byte[].They can > move {{ByteBuffer.position}} correctly when we have read the data. > 2. {{processUnwrappedData}} no longer use any extra memory. > 3. Maintaining a buffer pool in each {{Connection}}. -- This message was sent by Atlassian JIRA (v6.3.4#6332)