[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14075676#comment-14075676
]
Vijay commented on CASSANDRA-7438:
----------------------------------
Pushed the branch to https://github.com/Vijay2win/cassandra/tree/7438
{quote}Maybe delay Win port{quote}
We should be fine, lruc is configurable with the Serialization cache.
{quote}unclean shutdown (kill -9) does not delete the so/dylib file{quote}
Yeah it works in unix, but the problem is i don't have a handle since its a
temp file after restart. So it is a best effort for cleanups.
{quote}SWIGTYPE_p_item and SWIGTYPE_p_p_item are unused {quote}
Auto generated and can be removed but will be generated every time swig is run.
{quote}Generally the lruc code could be more integrated in C* code{quote}
The problem is it produces a circular dependency, please look at
df3857e4b9637ed6a5099506e95d84de15bf2eb7 where i removed those (the DOSP added
back will still need to wrapped around by Cassandra's DOSP).
{quote}Naming of max_size, capacity{quote}
Yeah let me make it consistent, the problem was i was trying to fit everything
into Guava interface.
{quote}remove hotN or return an array/list instead{quote}
Or may be do memcpy on keys, since this doesn't need optimization (will fix).
{quote}shouldn't there be something like a yield{quote}
Actually i removed it recently adding or removing doesn't give much performance
gains, as a good citizen should add it back.
{quote}Seems like the C code was not cleaned up{quote}
This cannot be removed and needed for test cases.
> 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)
