[ 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)