[
https://issues.apache.org/jira/browse/CASSANDRA-7438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14225592#comment-14225592
]
Ariel Weisberg commented on CASSANDRA-7438:
-------------------------------------------
bq. I thought we discussed this already... Yeah that was suppose to take care
by this comment "Next commit will have conditions instead (similar to C
implementation).", have not committed it yet
Sorry my bad.
Reentrant lock is just a counter of the number of acquisitions. You could do an
8-byte lock field, store the thread-id in the first 4-byte sand the counter in
the next 4-bytes. We probably want these to be 8-byte aligned so they don't
cross cache lines.
bq. Are you talking about setting Just setting 1 for lock and 0 for unlock?
Hmmm, alright thats doable... i am guessing you have already seen how
ReentrantLock implements locking.
You could do it in 8-bytes since pointers are actually only six bytes. The two
higher order bytes are just the highest order bit sign extended on current
Intel processors. CAS the pointer and use the highest order bit to represent
locked/unlocked.
> 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)
