cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefania (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8897) Remove FileCacheService, instead pooling the buffers
Date Wed, 22 Apr 2015 14:29:59 GMT


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:
>             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

This message was sent by Atlassian JIRA

View raw message