[
https://issues.apache.org/jira/browse/CASSANDRA-16681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17544221#comment-17544221
]
Benedict Elliott Smith commented on CASSANDRA-16681:
----------------------------------------------------
bq. 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.
Because we do not modify the logic in any other way, we just pass `isOwner`.
The public API is not modified, it is entirely internal to `BufferPool`.
bq. 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.
See above. Code analysis is simpler, as less is changed. I also disagree this
makes it significantly more complex even from first principles, particularly if
we suitably name the methods to make clear the semantics.
bq. 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.
No, this would behave correctly as we would be invoking it on the tinyPool that
we own, and so we would pass `isOwner = true`
bq. do we even really need it that much to recycle at all when we notice an
owned buffer is completely free
Lazy recycling can introduce more pathological behaviour, particularly for
`TinyPool` as we may have large allocations that have all been freed, and a
single tiny slither in a number of tiny pools that prevent them from being
released. If these are themselves part of mostly free _chunks_ we could end up
exhausting our global pool entirely without any of it being in use.
> 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: [email protected]
For additional commands, e-mail: [email protected]