maint: Remove use of folly/ThreadCachedInt

[ianthomas23]

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 the folly code plus use of boost::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 original folly 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 than folly's, requiring fewer atomics.

New class ThreadCachedInt in thread_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 using folly's own ThreadLocalPtr this uses boost::thread_specific_ptr. The folly source code claims that their implementation is 4x faster than the boost 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 here

ArcticDB/cpp/arcticdb/util/allocator.cpp

Lines 286 to 288 in 23b3b94

	#if defined(__linux__) && defined(__GLIBC__)
	malloc_trim(0);
	#endif

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.

[jjerphan]

LGTM. Thank you, @ianthomas23.

I would refer to @willdealtry's final decision, especially for potential regressions which might not be caught by the ASV benchmark suite.

[jjerphan]

This implementation LGTM!

I think it might be useful to mention that this implementation is a modification of one of folly, as you mentioned in the description of this PR. There's no problem with it since folly is Apache-2.0 licensed.

What do you think?

[ianthomas23]

Good idea.

[ianthomas23]

I have added extra clarification in the source code that this is derived from folly's implementation.