[
https://issues.apache.org/jira/browse/HBASE-21916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16771561#comment-16771561
]
stack commented on HBASE-21916:
-------------------------------
Nice class comment [~openinx] on the allocator.
How do I extract info on how well the allocator is doing? Perhaps I have to up
sizes? Are there logs or metrics I'd look at?
Should ByteBufferCleaner be doing a 'free' rather than a 'clean' of memory
(Should it have a different name?)
The return of a Pair with the allocation accompanied by the deallocator seems
unnatural. Why can't I call Allocator#free passing in the allocation to free?
For another issues, should we be using a pool at all? On a machine with 48 or
more CPUs, having them all stall to go via a synchronization block to get a bit
of memory and then to do cleanup might cost more than it saves?
> Abstract an ByteBuffAllocator to allocate/free ByteBuffer in ByteBufferPool
> ---------------------------------------------------------------------------
>
> Key: HBASE-21916
> URL: https://issues.apache.org/jira/browse/HBASE-21916
> Project: HBase
> Issue Type: Sub-task
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: HBASE-21916.v1.patch, HBASE-21916.v2.patch,
> HBASE-21916.v3.patch, HBASE-21916.v4.patch, HBASE-21916.v5.patch
>
>
> Now our read/write path allocate ByteBuffer from the ByteBufferPool, but we
> need consider the minSizeForReservoirUse for better utilization, those
> allocate/free api are some static methods, not so good to use.
> For HBASE-21879, we need an universal ByteBuffer allocator to manage all the
> ByteBuffers through the entire read path, so create this issue.
> Will upload a patch to abstract an ByteBufAllocator.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
