Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 21 Apr 2015 14:52:59 +0000 (UTC)
From: "Benedict (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12779117.1425402116000.62417.1429627979250@Atlassian.JIRA>
In-Reply-To: <JIRA.12779117.1425402116000@Atlassian.JIRA>
References: <JIRA.12779117.1425402116000@Atlassian.JIRA>
 <JIRA.12779117.1425402116970@arcas>
Subject: [jira] [Commented] (CASSANDRA-8897) Remove FileCacheService,
 instead pooling the buffers
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-8897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14505056#comment-14505056 ] 

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