[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14190711#comment-14190711
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
Did a walkthrough to lruc 0.7, too...
Altogether +1 on the current state :)
Just one NIT:
* Move {{Preconditions.checkArgument(capacity > 0 ...}} in {{LRUCache.java}}
from {{capacity()}} to {{setCapacity}}
One thing regarding saved row caches: We should ensure that changes in the
serialized format of saved row caches are detected (and either converted during
load or just discarded)
Comments would be nice to have in a future version.
* Think you need to add the APLv2 license header to all source files ;)
* The NEWS, COPYING and AUTHORS files in {{lruc/src/native}} and {{lurk}} are
blank
* {{stats}} struct is heavily used using CAS - maybe think of aligning the
individual values to separate CPU cache lines to reduce CPU cache refreshes
* similar for {{item.refcount}} - it refcount is updated, the whole cache line
needs to be re-fetched (CPU)
* {{o.a.c.cache.ICacheProvider.RowKeySerializer}} tries to „compress“ the two
{{long}} values of UUID via
{{EncodedDataOutputStream}}/{{EncodedDataInputStream}} - this is usually not
possible for long values of a UUID resulting in bigger serialized
representations than necessary (this is what the default serialization e.g.
UUIDSerializer does)
> Serializing Row cache alternative (Fully off heap)
> --------------------------------------------------
>
> Key: CASSANDRA-7438
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7438
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: Linux
> Reporter: Vijay
> Assignee: Vijay
> Labels: performance
> Fix For: 3.0
>
> Attachments: 0001-CASSANDRA-7438.patch
>
>
> Currently SerializingCache is partially off heap, keys are still stored in
> JVM heap as BB,
> * There is a higher GC costs for a reasonably big cache.
> * Some users have used the row cache efficiently in production for better
> results, but this requires careful tunning.
> * Overhead in Memory for the cache entries are relatively high.
> So the proposal for this ticket is to move the LRU cache logic completely off
> heap and use JNI to interact with cache. We might want to ensure that the new
> implementation match the existing API's (ICache), and the implementation
> needs to have safe memory access, low overhead in memory and less memcpy's
> (As much as possible).
> We might also want to make this cache configurable.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
