[
https://issues.apache.org/jira/browse/CASSANDRA-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507160#comment-14507160
]
Stefania commented on CASSANDRA-8897:
-------------------------------------
bq. The normal free count does not need to be volatile (which would make writes
expensive), because the other thread can piggy-back on its own free count
variable's volatile status to perform a volatile read of the normal count (and
the normal thread does not need to access it with volatile semantics)
This is because of the happens-before semantic of volatile in Java, right?
Just to be clear, to confirm we are thinking of the same counts:
- A normal free count, not volatile, this is increased by the owning thread
each time a buffer is released.
- An atomic free count, this is increased by a non-owning thread via CAS each
time a buffer is released by passing ownership by mistake.
- The combined count: normal free count + atomic free count
When combined count == chunk capacity then we recycle the chunk as long as we
can CAS the atomic free count so that combined count becomes chunk capacity + 1.
The other points you raise make sense, limiting the size to a power of 2 with a
minimum of 64 is a great idea, at the moment the max size is actually 64k
because that is the default buffer size (CASSANDRA-8894 might allow lowering to
32k) but it doesn't matter as the encoding fits anyway.
> Remove FileCacheService, instead pooling the buffers
> ----------------------------------------------------
>
> Key: CASSANDRA-8897
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8897
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Benedict
> Assignee: Stefania
> Fix For: 3.0
>
>
> After CASSANDRA-8893, a RAR will be a very lightweight object and will not
> need caching, so we can eliminate this cache entirely. Instead we should have
> a pool of buffers that are page-aligned.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
