[ https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14072361#comment-14072361 ]
Robert Stupp commented on CASSANDRA-7438: ----------------------------------------- Some minor notes: * https://github.com/Vijay2win/lruc/blob/master/src/main/java/com/lruc/api/LRUCache.java#L58 calls keySerializer.serializedSize(key) twice * https://github.com/Vijay2win/lruc/blob/master/src/main/java/com/lruc/api/LRUCache.java#L58 + next instruction do two JNI calls. Maybe it gains some performance to pass a {{new long[2]}} to a (new) {{lrucJNI.lruc_items_alloc}} method that allocates memory for two items (saves one JNI savepoint) To implement full off-heap in Java would require our own memory management or usage of an offheap management lib (couldn't find any straightaway). The only projects I know that have "flexible" memory off-heap allocation are netty and grizzly - but I don't know how they perform. Integration tests should be done on most important platforms like Linux x64, OSX, Win64. I think we can omit 32 bit platforms. I can help testing it on OSX and Win if needed. There should be a "standardized" test that aggressively uses off-heap data (put, get, replace, putIfAbsent, etc) using some threads (not too many - maybe 2xCPU-cores). [~vijay2...@yahoo.com] - did you try different malloc implementations? > 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)