[
https://issues.apache.org/jira/browse/HBASE-22802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16901674#comment-16901674
]
Zheng Hu commented on HBASE-22802:
----------------------------------
bq. I think the ByteBuff will be released in HFileScannerImpl#close, is that
right?
No only closing, once we've sent the cells to rpc client then we can release
the ByteBuff. because the RPC is finished, the memory allocated from
ByteBuffAllocator won't be used any more. Of course, if close the scanner,
we must also release the BB.
bq. and there is no need to share the same refCnt with BucketEntry like what
ByteBufferIOEngine to do (code in BucketEntry#wrapAsCacheable)
Seems true, but my concerns is: we maintain the RefCnt for BucketEntry because
we want to know when we can free the memory area in IOEngine ( mostly in
ByteBufferIOEngine). Once the rpc reference count decrease to zero, we can try
to evict the block if neccessary. For FileIOEngine, if the ByteBuff is
allocated from ByteBuffAllocator, then its refCnt should be a seperate one, and
if won't pass the BucketEntry's refCnt to the ByteBuff in HFIleBlock, then how
we know when can do the block eviction ? Says we must consider the two issues
for FileIOEngine : release the BB from ByteBuffAllocator & when we can do the
block eviction.
> Avoid temp ByteBuffer allocation in FileIOEngine#read
> -----------------------------------------------------
>
> Key: HBASE-22802
> URL: https://issues.apache.org/jira/browse/HBASE-22802
> Project: HBase
> Issue Type: Improvement
> Components: BucketCache
> Reporter: chenxu
> Priority: Major
> Attachments: profile_mem_alloc.png
>
>
> a temp ByteBuffer was allocated each time FileIOEngine#read was called
> {code:java}
> public Cacheable read(BucketEntry be) throws IOException {
> long offset = be.offset();
> int length = be.getLength();
> Preconditions.checkArgument(length >= 0, "Length of read can not be less
> than 0.");
> ByteBuffer dstBuffer = ByteBuffer.allocate(length);
> ...
> }
> {code}
> we can avoid this by use of ByteBuffAllocator#allocate(length) after
> HBASE-21879
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
