[
https://issues.apache.org/jira/browse/CASSANDRA-11452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15240902#comment-15240902
]
Ben Manes commented on CASSANDRA-11452:
---------------------------------------
The simple hack recycling when the hash codes are equal seems to work well.
This would be done in {{evictFromMain}} at the end after the candidate was
evicted. Since a weighted cache might evict multiple entries we have to reset
the victim for the next loop.
{code}
// Recycle to guard against hash collision attacks
if (victimKey.hashCode() == candidateKey.hashCode()) {
Node<K, V> nextVictim = victim.getNextInAccessOrder();
accessOrderProbationDeque().moveToBack(victim);
victim = nextVictim;
}
{code}
The LIRS paper's traces (short) indicate that the difference noise.
{{
multi1: 55.28 -> 55.40
multi2: 48.37 -> 48.42
multi3: 41.78 -> 42.00
gli: 34.15 -> 34.06
ps: 57.15 -> 57.17
sprite: 54.95 -> 55.33
cs: 30.19 -> 29.82
loop: 49.95 -> 49.90
2_pools: 52.02 -> 51.96
}}
Tomorrow I'll check some of the ARC traces, clean-up the patch, and convert
Branimir into a unit test. Thoughts?
> Cache implementation using LIRS eviction for in-process page cache
> ------------------------------------------------------------------
>
> Key: CASSANDRA-11452
> URL: https://issues.apache.org/jira/browse/CASSANDRA-11452
> Project: Cassandra
> Issue Type: Improvement
> Components: Local Write-Read Paths
> Reporter: Branimir Lambov
> Assignee: Branimir Lambov
>
> Following up from CASSANDRA-5863, to make best use of caching and to avoid
> having to explicitly marking compaction accesses as non-cacheable, we need a
> cache implementation that uses an eviction algorithm that can better handle
> non-recurring accesses.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
