[
https://issues.apache.org/jira/browse/HBASE-21957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16814186#comment-16814186
]
Zheng Hu commented on HBASE-21957:
----------------------------------
The current block eviction workflow is:
1. evict from RamCache firstly;
2. check BuckeEntry's refCnt , if zero and marked as evicted, then:
2.1. removing BucketEntry (which store the offset & len) from backingMap;
2.2. the BucketAllocator will free its allocated offset & len;
2.3. update the cache statistics
I think we should wrap all the above steps as an ByteBuffAllocator#Recycler,
and set it into the ByteBuff reading from IOEngine. Then once the RPC layer
called an HFileBlock#release, the ByteBuff in HFileBlock will check its
refCnt, if decrease to zero, then trigger the Recycler to recycle its memory
back to BucketAllocator. In that time, the uppler layer won't need to care
about where is the block come from (either from ByteBuffAllocator, or from
BucketAllocator), if they don't need the block any more, then just call
HFileBlock#release.
> Unify refCount of BucketEntry and refCount of hbase.nio.ByteBuff into one
> -------------------------------------------------------------------------
>
> Key: HBASE-21957
> URL: https://issues.apache.org/jira/browse/HBASE-21957
> Project: HBase
> Issue Type: Sub-task
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
>
> After HBASE-12295, we have block with MemoryType.SHARED or
> MemoryType.EXCLUSIVE, the block in offheap BucketCache will be shared, and
> have an reference count to track its life cycle. If no rpc reference to the
> shared block, then the block can be evicted.
> while after the HBASE-21916, we introduced an refcount for ByteBuff, then I
> think we can unify the two into one. tried to fix this when preparing patch
> for HBASE-21879, but seems can be different sub-task, and it won't affect the
> main logic of HBASE-21879, so create a seperate one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
