[ 
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)

Reply via email to