[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14284230#comment-14284230
]
Ariel Weisberg commented on CASSANDRA-7438:
-------------------------------------------
I am +1 conditional on the library throwing OOME if the allocator fails. It
should be the caller of the library that decides how to handle the situation
not the library IMO.
There are also still some internal properties inside OHC that are don't have a
prefix.
I noticed you fixed some C* bugs
https://github.com/snazy/cassandra/compare/7438-pluggable#diff-98f5acb96aa6d684781936c141132e2aL1915
Do those fixes need to be backported?
Can you publish a new version to maven central so I can benchmark it vs the old
cache implementation?
> 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: Robert Stupp
> 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)
