[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544219#comment-17544219
]
Piotr Kolaczkowski edited comment on CASSANDRA-16681 at 5/31/22 8:25 AM:
-------------------------------------------------------------------------
# How is that simpler than an internal check for currentThread? It adds a
parameter to the public API of LocalPool and moves the burden of correctness on
the caller.
# It would make the code analysis harder - it is not immediately obvious the
correct thread would touch the private non-synchronized stuff. In my patch it
is obvious.
# I expect the majority of buffers are returned by the same thread which
allocated it. So if you disable recycling of buffers invoked from tinypool in
all cases of indirect returns, it would be overly conservative.
BTW point 3 leads me to thinking - do we even really need it that much to
recycle at all when we notice an owned buffer is completely free? Why not keep
it for future allocations from that thread? I can imagine eager recycling could
get us in some pathological edge-case performance problem if the caller
requests just one buffer, returns it, requests another, returns etc. In this
case such buffer would constantly travel between the GlobalPool and LocalPool
which kinda defeats the purpose of local pools.
was (Author: pkolaczk):
# How is that simpler than an internal check for currentThread? It adds a
parameter to the public API of LocalPool and moves the burden of correctness on
the caller.
# It would make the code analysis harder - it is not immediately obvious the
correct thread would touch the private non-synchronized stuff. In my patch it
is obvious.
# I expect the majority of buffers are returned by the same thread which
allocated it. So if you disable recycling of buffers invoked from tinypool in
all cases of indirect returns, it looks overly conservative.
BTW point 3 leads me to thinking - do we even really need it that much to
recycle at all when we notice an owned buffer is completely free? Why not keep
it for future allocations from that thread? I can imagine eager recycling could
get us in some pathological edge-case performance problem if the caller
requests just one buffer, returns it, requests another, returns etc. In this
case such buffer would constantly travel between the GlobalPool and LocalPool
which kinda defeats the purpose of local pools.
> org.apache.cassandra.utils.memory.LongBufferPoolTest - tests are flaky
> ----------------------------------------------------------------------
>
> Key: CASSANDRA-16681
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16681
> Project: Cassandra
> Issue Type: Bug
> Components: CI
> Reporter: Ekaterina Dimitrova
> Assignee: Piotr Kolaczkowski
> Priority: Normal
> Fix For: 3.11.x, 4.0.x, 4.x
>
> Attachments: 0001-Fix-memoryInUse-counter-in-BufferPool.patch,
> 0002-Multiple-fixes-in-BufferPool-and-LongBufferPoolTest.patch
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Jenkins history:
> [https://jenkins-cm4.apache.org/job/Cassandra-4.0/50/testReport/junit/org.apache.cassandra.utils.memory/LongBufferPoolTest/testPoolAllocateWithRecyclePartially/history/]
> Fails being run in a loop in CircleCI:
> https://app.circleci.com/pipelines/github/ekaterinadimitrova2/cassandra/844/workflows/945011f4-00ac-4678-89f6-5c0db0a40169/jobs/5008
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
