maint: Remove use of folly/ThreadCachedInt #1486
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Reference Issues/PRs
Fixes the 10th item of the folly replacement plan, issue #1412.
What does this implement or fix?
This removes the single use of
folly/ThreadCachedInt
. It is replaced by a partial vendoring of thefolly
code plus use ofboost::thread_specific_ptr
.ThreadCachedInt
is used to count the number of freed memory blocks. It is (presumably) not just implemented as an atomic integer count as thread locking would be too slow, so instead each thread has its own count and when a single thread's count exceeds some threshold it is added to the overall count. The originalfolly
implementation has two ways of reading the count which are slow (fully accurate) and fast (not fully accurate). ArcticDB only uses the fast option, so the implementation is much simpler thanfolly
's, requiring feweratomic
s.New class
ThreadCachedInt
inthread_cached_int.hpp
is derived from https://github.com/facebook/folly/blob/main/folly/ThreadCachedInt.h but containing only the subset of functionality required. Instead of usingfolly'
s ownThreadLocalPtr
this usesboost::thread_specific_ptr
. Thefolly
source code claims that their implementation is 4x faster than theboost
one:https://github.com/facebook/folly/blob/dbc9e565f54eabb40ad6600656ad9dea919f51c0/folly/ThreadLocal.h#L18-L20
but that claim dates from 12 years ago and this solution is simpler than theirs. This does need to be benchmarked against
master
to confirm that it is not measurably slower.Any other comments?
The only place this is ultimately used is to control when
malloc_trim
is called hereArcticDB/cpp/arcticdb/util/allocator.cpp
Lines 286 to 288 in 23b3b94
to release memory back to the system. This only occurs on Linux. Other OSes could have all of this code removed but this would be a bigger change with many
#ifdef
blocks, etc.