cassandra-commits mailing list archives

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


Benedict commented on CASSANDRA-8897:

bq. Are the logging gards something we always use for trace and debug or is there really a
big benefit when logging only with parametrized strings and no function calls?

Well, honestly I never investigated if the optimisation was worth it. I assumed that isXEnabled
would be a final variable lookup, inlinable, and hence extremely cheap. It looks like I was
wrong, and that not calling it first in the no-args instance is perhaps more efficient. This
is disappointing, though, and we should perhaps write our own logback logger (as well as our
own non-blocking appender). For this patch I don't mind which way we go, since both are widespread
in the codebase.

 bq. How is this possible since Allocator.allocateAligned() limits the byte buffer to the
exact capacity requested,

Oops, yes, my mistake. I misread the method you were using to align. Looking at the code again,
it looks to me like we could eliminate the ( == 0) branch though.

bq. Did you mean to have one thread unallocate the buffer from another thread pool or take
over the entire pool or other?

No, I mean in the scenario in which one thread _does_ deallocate another thread's buffer (by
mistake we pass ownership) we could have a second count variable that is updated only by threads
that detect this scenario (and updated via CAS), so that we can still maintain a safe count.
However it is challenging in this scenario to ensure we always detect when the count reaches
full, so is perhaps something to leave for another ticket (and only detect that we have deallocated
on another thread, log a panic, and accept we've leaked some memory). If you'd like to address
it in this ticket, do feel free though, since it does give us some greater safety.  We should
log errors either way, since this is not a target use case.

> 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