[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225453#comment-14225453
]
Vijay commented on CASSANDRA-7438:
----------------------------------
{quote}
Segments are hash buckets correct?
{quote}
Yes and the way memcached and lruc is does the rehashing is based on this
algorithm, and hence yes... That was the argument earlier about JNI based
solution. (Also another reason I was talking about of configurable hash
expansion capability in my previous comment)
{code}
unsigned long current_size = cas_incr(stats.hash_items, 1);
if (current_size > (hashsize(hashpower) * 3) / 2) {
assoc_start_expand();
}
{code}
if we don't like the constant overhead of the cache in heap and If you are
talking about CAS which we already do for ref counting, as mentioned before we
need an alternative strategy for global locks for rebalance if we go with lock
less strategy.
{quote}
The task submitted to the executor doesn't check whether another rehash is
required it just does it.
{quote}
Until you complete a rehash you don't know if you need to hash again or not...
Am i missing something?
> 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)
