Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Date: Sat, 11 Apr 2015 00:53:12 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: dev@hbase.apache.org
Message-ID: <JIRA.12526508.1318277690000.60608.1428713592683@Atlassian.JIRA>
In-Reply-To: <JIRA.12526508.1318277690000@Atlassian.JIRA>
References: <JIRA.12526508.1318277690000@Atlassian.JIRA>
 <JIRA.12526508.1318277690804@arcas>
Subject: [jira] [Resolved] (HBASE-4569) Simpler implementation for slab
 cache
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-4569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrew Purtell resolved HBASE-4569.
-----------------------------------
    Resolution: Not A Problem

SlabCache is gone post 0.98

> Simpler implementation for slab cache
> -------------------------------------
>
>                 Key: HBASE-4569
>                 URL: https://issues.apache.org/jira/browse/HBASE-4569
>             Project: HBase
>          Issue Type: Improvement
>          Components: regionserver
>    Affects Versions: 0.92.0
>            Reporter: Todd Lipcon
>         Attachments: hbase-4569.txt
>
>
> I spent a little bit of time last night hacking on the slab cache implementation to make it a little simpler. The change is:
> - no longer has the composition of SlabCache containing a SingleSizeCache per slab size. SlabCache holds its own slabs
> - no longer use guava's map implementations to handle a size-bounded cache. Instead, manages its own LRU linked list
> - significantly less clever about synchronization. since this is an L2 cache, it should be less contended than the L1 cache, and I think we can afford to be dumb.
> - should have less memory usage since there's only one map entry per key instead of several.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)