[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072970#comment-14072970
]
Robert Stupp commented on CASSANDRA-7438:
-----------------------------------------
bq. no tools that aren't available through unsafe/NativeAllocator
It's "plain old" {{malloc}}/{{free}}.
But regardless whether JVM's native allocator or malloc is used - it needs to
be thoroughly tested to ensure that there are no memory leaks.
I'm not sure if it is possible with JNI code: we should also check different C
malloc implementations - there are differences.
Altogether IMO this (lruc) one is a good start to prevent GC - we can fully
optimize it later. Maybe it's possible to create a "pure Java off heap"
solution without the annoying JNI-savepoint.
Ah - and we should check lruc against both Java7 and Java8 - I think there are
optimizations in Java8 regarding JNI (or at least there were some discussions -
did not follow that).
> 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.2#6252)