[
https://issues.apache.org/jira/browse/CASSANDRA-9738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735591#comment-14735591
]
Ariel Weisberg commented on CASSANDRA-9738:
-------------------------------------------
Just going off of coverage from "ant test" not including your work today. I
have had some bad luck recently with emma claiming stuff is not covered.
Hopefully it's accurate in these instances.
* Serializers.LegacyClusteringPrefixSerializer.deserialize isn't tested. Is
that blocked by CASSANDRA10237?
* IndexInfo.skip isn't labeled as covered and neither is serializedSize
* RowIndexEntry.equals is not covered, neither is hashCode, same for
RIE.IndexedEntry
* RowIndexEntry.Serializer.serialize doesn't test manually serializing the old
version
* RowIndexEntry.IndexedEntry constructor doesn't test loading the old version
* RowIndexEntry.IndexedEntry.indexInfo doesn't test the old version, also the
branch at the end where it stores the offset it happens to know about after
finishing
* RowIndexEntry.IndexedEntry.indexInfo does it have to do that loop for already
discovered offsets? Can you store that value and not loop?
* RIE.IndexedEntry.indexCount() could store the offset as a constant, also
firstIndexInfoOffset
* RIE.IndexedEntry.promotedSize for the old version not covered
* Slice.Serializer.skip() is not tested/covered, neither is serialized size or
part of deserialize, but you didn't change the latter two
* [RowIndexEntyrTest has commented out
code|https://github.com/apache/cassandra/compare/cassandra-3.0...snazy:9738-key-cache-ohc#diff-7972c5d16db58cd0a0e63e95c4de264aR203]
Reviewing test contents now. Also going to update and look at your latest.
> 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.0 rc1
>
>
> 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)