hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Purtell (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-16703) Explore object pooling of SeekerState
Date Sat, 24 Sep 2016 22:49:20 GMT

    [ https://issues.apache.org/jira/browse/HBASE-16703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15519758#comment-15519758

Andrew Purtell commented on HBASE-16703:

There's no reason we can't hold on to earlier allocated SeekerState objects, and their existing
byte arrays, since they'll reallocate if needed.  A wrinkle is SeekerState is shallow cloned
with a wrapper class ClonedSeekerState for use by upper layers. Is that cloning sufficient
to protect against reuse of the base SeekerState? I think that is the intent. If insufficient
we can still do reference counting of SeekerState objects for deciding when to return them
to a shared pool. Also, we can have the pools be thread locals to avoid cross thread synchronization
overheads and still get a win on reducing allocations substantially.

> Explore object pooling of SeekerState
> -------------------------------------
>                 Key: HBASE-16703
>                 URL: https://issues.apache.org/jira/browse/HBASE-16703
>             Project: HBase
>          Issue Type: Task
>            Reporter: Andrew Purtell
> In read workloads 35% of the allocation pressure produced by servicing RPC requests comes
from SeekerState.<init> of the DataBlockEncoder implementation currently in use, where
we allocate two byte arrays of INITIAL_KEY_BUFFER_SIZE in length. There's an opportunity for
object pooling of SeekerState here. Subsequent code checks if those byte arrays are sized
sufficiently to handle incoming data to copy. The arrays will be resized if needed. 

This message was sent by Atlassian JIRA

View raw message