[
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
(v6.3.4#6332)
