[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14231817#comment-14231817
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
[~vijay2...@yahoo.com] can you explain what kind of bugs?
bq. licensing and attribution requirements
It's already in C* code base in exactly the same way.
Also pushed some changes:
* increased max# of segment and buckets to 2^30 (means approx 1B segments times
1B bucket)
* add some prototype for direct I/O for row cache serialization (zero copy) -
just as a demo (just coded, not tested yet)
* uses Unsafe for value (de)serialization
* move (most) statistic counters to OffHeapMap to reduce contention caused by
volatile (really makes sense)
* remove use of guava cache API
* corrected and improved key comparison
Regarding the 64 bit hash. It's 64 bit since OHC takes the the most significant
bits for the segment and the least significant bits for the hash inside a
segment. Both are limited to 30 bits = 60 bits.
> 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, tests.zip
>
>
> 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)
