[
https://issues.apache.org/jira/browse/HBASE-26105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385966#comment-17385966
]
Yutong Xiao commented on HBASE-26105:
-------------------------------------
I think that is the purpose of the containsBlock method of FirstLevelCache
interface. While containsBlock method should be very fast. That makes the
getBlock method of CombinedBC is almost as fast as a single L1 or L2 cache.
Otherwise the time cost of this method is doubled as the single cache when L1
is miss. What do you think?
> Rectify the expired TODO comment in CombinedBC
> ----------------------------------------------
>
> Key: HBASE-26105
> URL: https://issues.apache.org/jira/browse/HBASE-26105
> Project: HBase
> Issue Type: Improvement
> Components: BlockCache
> Reporter: Yutong Xiao
> Assignee: Yutong Xiao
> Priority: Trivial
>
> In the method getBlock in CombinedBC, there is a TODO comment as follows:
> {code:java}
> @Override
> public Cacheable getBlock(BlockCacheKey cacheKey, boolean caching,
> boolean repeat, boolean updateCacheMetrics) {
> // TODO: is there a hole here, or just awkwardness since in the lruCache
> getBlock
> // we end up calling l2Cache.getBlock.
> // We are not in a position to exactly look at LRU cache or BC as
> BlockType may not be getting
> // passed always.
> boolean existInL1 = l1Cache.containsBlock(cacheKey);
> if (!existInL1 && updateCacheMetrics && !repeat) {
> // If the block does not exist in L1, the containsBlock should be
> counted as one miss.
> l1Cache.getStats().miss(caching, cacheKey.isPrimary(),
> cacheKey.getBlockType());
> }
> return existInL1 ?
> l1Cache.getBlock(cacheKey, caching, repeat, updateCacheMetrics):
> l2Cache.getBlock(cacheKey, caching, repeat, updateCacheMetrics);
> }
> {code}
> The TODO comment is expired. While in CombinedBC, L2 is not the victim
> handler of L1.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
