[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198368#comment-14198368
]
Jonathan Ellis commented on CASSANDRA-7438:
-------------------------------------------
Here's me in July:
bq. I'm not wild about taking on the complexity of building and distributing
native libraries if we have a reasonable alternative. Vijay what do we win with
the native approach over using java unsafe?
The objection at the time was,
bq. The win is that we can now have Caches which can be bigger than JVM with
zero GC overhead on the items. Unsafe approach will hold the references in
memory and the overhead on them is reasonably high compared to the native
approach (example of it is an integer key's) and in addition if we use hash map
we have segments with locks (also there the references in the queue), so it is
not a straight forward approach either.
... but as Ariel said, we can use the same technique to hold references
off-heap with Unsafe, as with JNI. 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)
