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