[
https://issues.apache.org/jira/browse/HBASE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13214368#comment-13214368
]
Lars Hofhansl commented on HBASE-5347:
--------------------------------------
That should work, and it would not put any burden on the writer on the author
of a new Filter.
I need to look at the patch again to get a sense of a extend of extra code we
need to sprinkle all over the HBase code base to account for the KVs. On first
path it didn't seem horrid.
I am generally curious, though, (almost) all the cached blocks have the exact
same size, right? The GC (in theory) should have a relatively easy time to
reuse the freed space (and it's interesting - to me anyway - that it doesn't do
this efficiently).
> GC free memory management in Level-1 Block Cache
> ------------------------------------------------
>
> Key: HBASE-5347
> URL: https://issues.apache.org/jira/browse/HBASE-5347
> Project: HBase
> Issue Type: Improvement
> Reporter: Prakash Khemani
> Assignee: Prakash Khemani
> Attachments: D1635.5.patch
>
>
> On eviction of a block from the block-cache, instead of waiting for the
> garbage collecter to reuse its memory, reuse the block right away.
> This will require us to keep reference counts on the HFile blocks. Once we
> have the reference counts in place we can do our own simple
> blocks-out-of-slab allocation for the block-cache.
> This will help us with
> * reducing gc pressure, especially in the old generation
> * making it possible to have non-java-heap memory backing the HFile blocks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
