[
https://issues.apache.org/jira/browse/HBASE-22114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16804484#comment-16804484
]
Andrew Purtell commented on HBASE-22114:
----------------------------------------
WDYT [~busbey] ?
Confirmed build is ok when Java 7.
Confirmed build is ok when Java 8.
Confirmed assembly includes hbase-tinylfu-blockcache and caffiene jars in lib/
if built with Java 8.
New unit tests pass in new hbase-tinylfu-blockcache module.
Other unit tests pass.
Confirmed by hand that test clusters will start with
hfile.block.cache.policy=TinyLFU when built with Java 8.
> Port HBASE-15560 (TinyLFU-based BlockCache) to branch-1
> -------------------------------------------------------
>
> Key: HBASE-22114
> URL: https://issues.apache.org/jira/browse/HBASE-22114
> Project: HBase
> Issue Type: Sub-task
> Reporter: Andrew Purtell
> Assignee: Andrew Purtell
> Priority: Major
> Fix For: 1.5.0
>
> Attachments: HBASE-22114-branch-1.patch
>
>
> HBASE-15560 introduces the TinyLFU cache policy for the blockcache.
> W-TinyLFU ([research paper|http://arxiv.org/pdf/1512.00727.pdf]) records the
> frequency in a counting sketch, ages periodically by halving the counters,
> and orders entries by SLRU. An entry is discarded by comparing the frequency
> of the new arrival (candidate) to the SLRU's victim, and keeping the one with
> the highest frequency. This allows the operations to be performed in O(1)
> time and, though the use of a compact sketch, a much larger history is
> retained beyond the current working set. In a variety of real world traces
> the policy had [near optimal hit
> rates|https://github.com/ben-manes/caffeine/wiki/Efficiency].
> The implementation of HBASE-15560 uses several Java 8 idioms, depends on JRE
> 8+ type Optional, and has dependencies on libraries compiled with Java 8+
> bytecode. It could be backported to branch-1 but must be made optional both
> at compile time and runtime, enabled by the 'build-with-jdk8' build profile.
> The TinyLFU policy must go into its own build module.
> The blockcache must be modified to load L1 (and perhaps L2)
> implementation/policy dynamically at startup by reflection, with
> implementation classname specified in site configuration. This modification
> must be forward ported to maintain configuration sanity among the branches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
