Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Mon, 31 Aug 2015 17:29:46 +0000 (UTC)
From: "Ariel Weisberg (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12842931.1436201637000.212427.1441042186395@Atlassian.JIRA>
In-Reply-To: <JIRA.12842931.1436201637000@Atlassian.JIRA>
References: <JIRA.12842931.1436201637000@Atlassian.JIRA>
 <JIRA.12842931.1436201637115@arcas>
Subject: [jira] [Commented] (CASSANDRA-9738) Migrate key-cache to be fully
 off-heap
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14723736#comment-14723736 ] 

Ariel Weisberg commented on CASSANDRA-9738:
-------------------------------------------

OK, looks like what I was thinking at a high level. Since it is in progress I won't go deeper yet. I would include the index info offsets in the serialization and just populate them from the start so random access is simple. It's not going to be a worse memory impact than the existing Java object graph that has the array. Caching the last used IndexInfo is going to force a little bit of promotion. Not sure how much.

It's not going to be easy, but if we can operate on the IndexInfo as a ByteBuffer we can avoid deserializing them during the binary search. Getting ClusteringComparator and ClusteringPrefix to that point does look hard. We measure as is and see if it's enough garbage and to matter.

Reference counting shouldn't be too bad. In all the cases I could find the index info is consumed immediately and discarded or composed into an iterator implementing Closable. There is a bit of rope to hang to hang ourselves with there for long lived iterators pinning stuff in the cache. This is probably something we should test in OHC.

> Migrate key-cache to be fully off-heap
> --------------------------------------
>
>                 Key: CASSANDRA-9738
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9738
>             Project: Cassandra
>          Issue Type: Sub-task
>            Reporter: Robert Stupp
>            Assignee: Robert Stupp
>             Fix For: 3.0 beta 2
>
>
> Key cache still uses a concurrent map on-heap. This could go to off-heap and feels doable now after CASSANDRA-8099.
> Evaluation should be done in advance based on a POC to prove that pure off-heap counter cache buys a performance and/or gc-pressure improvement.
> In theory, elimination of on-heap management of the map should buy us some benefit.


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