[
https://issues.apache.org/jira/browse/CASSANDRA-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507032#comment-14507032
]
Benedict commented on CASSANDRA-8897:
-------------------------------------
bq. To to ensure we detect when the chunk is fully free, isFree() is no longer
very cheap since the ordinary count must become volatile, and the atomic count
must also be read (and its value is also a volatile int). So I think you meant
to keep isFree() extremely cheap and check in some other place? Still, the
ordinary count would have to be volatile surely?
A volatile read is pretty much free in this context on any platforms we are
likely running on. However we can avoid this problem and the atomic boolean
issue, by overloading the atomic free count's meaning: if we increment it by
one using cas when our combined count is equal to the free count, then we can
ensure only one thread takes ownership of the action of returning the chunk
(i.e. the on that incremented it by one). The normal free count does not need
to be volatile, 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)
I would prefer we use AtomicIntegerFieldUpdater than AtomicInteger, so we can
keep the overhead of this class down.
bq. For the rest, we basically attach a thread id to the chunk to determine
which thread owns it, if any, and we attach the chunk to the buffers as you
suggested.
Why not just attach the LocalPool object itself? (technically we could have the
same id reused, but not a major risk. But it is probably cleaner to just use
the LocalPool anyway)
bq. but as it turns out we need to unpack the position before sorting so we
could change it to an array of 24 shorts rather than 12 ints
Well, since we know the size of the buffer has to be <= 32Kb, we can safely
encode both size and position in the lower 31 bits of the int, with the
position occurring in the upper 16 bits, at which point we can safely sort the
ints.
However we can go further: if we impose a lower limit of, say, 64 bytes on the
size of the allocated buffer (rounding up if smaller) then since we operate on
powers of 2, we have only 10 possible values to encode (11 if you include
64Kb). We also have only {{2^16 / 2^6 = 2^10}} positions to encode, So we need
10 bits for the position, and only 4 bits for the size, which can all fit in
the positive component of a single short.
Of course, we probably need to impose a lower bound of 4K to ensure page
alignment for > 4Kb buffers, or when allocating across a page boundary we need
to realign ourselves and "free" the buffers we don't allocate, by logging them
in this list
> 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)
