2019-05-10 18:53:33 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
|
|
|
//
|
|
|
|
// Copyright (c) 2012 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <cassert>
|
2022-10-25 18:50:38 +00:00
|
|
|
|
Move the filter readers out of the block cache (#5504)
Summary:
Currently, when the block cache is used for the filter block, it is not
really the block itself that is stored in the cache but a FilterBlockReader
object. Since this object is not pure data (it has, for instance, pointers that
might dangle, including in one case a back pointer to the TableReader), it's not
really sharable. To avoid the issues around this, the current code erases the
cache entries when the TableReader is closed (which, BTW, is not sufficient
since a concurrent TableReader might have picked up the object in the meantime).
Instead of doing this, the patch moves the FilterBlockReader out of the cache
altogether, and decouples the filter reader object from the filter block.
In particular, instead of the TableReader owning, or caching/pinning the
FilterBlockReader (based on the customer's settings), with the change the
TableReader unconditionally owns the FilterBlockReader, which in turn
owns/caches/pins the filter block. This change also enables us to reuse the code
paths historically used for data blocks for filters as well.
Note:
Eviction statistics for filter blocks are temporarily broken. We plan to fix this in a
separate phase.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5504
Test Plan: make asan_check
Differential Revision: D16036974
Pulled By: ltamasi
fbshipit-source-id: 770f543c5fb4ed126fd1e04bfd3809cf4ff9c091
2019-07-16 20:11:23 +00:00
|
|
|
#include "port/likely.h"
|
2019-05-10 18:53:33 +00:00
|
|
|
#include "rocksdb/cache.h"
|
|
|
|
#include "rocksdb/cleanable.h"
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2019-05-10 18:53:33 +00:00
|
|
|
|
|
|
|
// CachableEntry is a handle to an object that may or may not be in the block
|
|
|
|
// cache. It is used in a variety of ways:
|
|
|
|
//
|
|
|
|
// 1) It may refer to an object in the block cache. In this case, cache_ and
|
|
|
|
// cache_handle_ are not nullptr, and the cache handle has to be released when
|
|
|
|
// the CachableEntry is destroyed (the lifecycle of the cached object, on the
|
|
|
|
// other hand, is managed by the cache itself).
|
|
|
|
// 2) It may uniquely own the (non-cached) object it refers to (examples include
|
|
|
|
// a block read directly from file, or uncompressed blocks when there is a
|
|
|
|
// compressed block cache but no uncompressed block cache). In such cases, the
|
|
|
|
// object has to be destroyed when the CachableEntry is destroyed.
|
|
|
|
// 3) It may point to an object (cached or not) without owning it. In this case,
|
|
|
|
// no action is needed when the CachableEntry is destroyed.
|
|
|
|
// 4) Sometimes, management of a cached or owned object (see #1 and #2 above)
|
|
|
|
// is transferred to some other object. This is used for instance with iterators
|
|
|
|
// (where cleanup is performed using a chain of cleanup functions,
|
|
|
|
// see Cleanable).
|
|
|
|
//
|
|
|
|
// Because of #1 and #2 above, copying a CachableEntry is not safe (and thus not
|
|
|
|
// allowed); hence, this is a move-only type, where a move transfers the
|
|
|
|
// management responsibilities, and leaves the source object in an empty state.
|
|
|
|
|
|
|
|
template <class T>
|
|
|
|
class CachableEntry {
|
2022-10-25 18:50:38 +00:00
|
|
|
public:
|
2019-05-10 18:53:33 +00:00
|
|
|
CachableEntry() = default;
|
|
|
|
|
|
|
|
CachableEntry(T* value, Cache* cache, Cache::Handle* cache_handle,
|
2022-10-25 18:50:38 +00:00
|
|
|
bool own_value)
|
|
|
|
: value_(value),
|
|
|
|
cache_(cache),
|
|
|
|
cache_handle_(cache_handle),
|
|
|
|
own_value_(own_value) {
|
2019-05-10 18:53:33 +00:00
|
|
|
assert(value_ != nullptr ||
|
2022-10-25 18:50:38 +00:00
|
|
|
(cache_ == nullptr && cache_handle_ == nullptr && !own_value_));
|
2019-05-10 18:53:33 +00:00
|
|
|
assert(!!cache_ == !!cache_handle_);
|
|
|
|
assert(!cache_handle_ || !own_value_);
|
|
|
|
}
|
|
|
|
|
|
|
|
CachableEntry(const CachableEntry&) = delete;
|
|
|
|
CachableEntry& operator=(const CachableEntry&) = delete;
|
|
|
|
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
2022-04-13 14:34:01 +00:00
|
|
|
CachableEntry(CachableEntry&& rhs) noexcept
|
|
|
|
: value_(rhs.value_),
|
|
|
|
cache_(rhs.cache_),
|
|
|
|
cache_handle_(rhs.cache_handle_),
|
|
|
|
own_value_(rhs.own_value_) {
|
2019-05-10 18:53:33 +00:00
|
|
|
assert(value_ != nullptr ||
|
2022-10-25 18:50:38 +00:00
|
|
|
(cache_ == nullptr && cache_handle_ == nullptr && !own_value_));
|
2019-05-10 18:53:33 +00:00
|
|
|
assert(!!cache_ == !!cache_handle_);
|
|
|
|
assert(!cache_handle_ || !own_value_);
|
|
|
|
|
|
|
|
rhs.ResetFields();
|
|
|
|
}
|
|
|
|
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
2022-04-13 14:34:01 +00:00
|
|
|
CachableEntry& operator=(CachableEntry&& rhs) noexcept {
|
2019-05-10 18:53:33 +00:00
|
|
|
if (UNLIKELY(this == &rhs)) {
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
|
|
|
ReleaseResource();
|
|
|
|
|
|
|
|
value_ = rhs.value_;
|
|
|
|
cache_ = rhs.cache_;
|
|
|
|
cache_handle_ = rhs.cache_handle_;
|
|
|
|
own_value_ = rhs.own_value_;
|
|
|
|
|
|
|
|
assert(value_ != nullptr ||
|
2022-10-25 18:50:38 +00:00
|
|
|
(cache_ == nullptr && cache_handle_ == nullptr && !own_value_));
|
2019-05-10 18:53:33 +00:00
|
|
|
assert(!!cache_ == !!cache_handle_);
|
|
|
|
assert(!cache_handle_ || !own_value_);
|
|
|
|
|
|
|
|
rhs.ResetFields();
|
|
|
|
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
2022-10-25 18:50:38 +00:00
|
|
|
~CachableEntry() { ReleaseResource(); }
|
2019-05-10 18:53:33 +00:00
|
|
|
|
|
|
|
bool IsEmpty() const {
|
|
|
|
return value_ == nullptr && cache_ == nullptr && cache_handle_ == nullptr &&
|
2022-10-25 18:50:38 +00:00
|
|
|
!own_value_;
|
2019-05-10 18:53:33 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
bool IsCached() const {
|
|
|
|
assert(!!cache_ == !!cache_handle_);
|
|
|
|
|
|
|
|
return cache_handle_ != nullptr;
|
|
|
|
}
|
|
|
|
|
|
|
|
T* GetValue() const { return value_; }
|
|
|
|
Cache* GetCache() const { return cache_; }
|
|
|
|
Cache::Handle* GetCacheHandle() const { return cache_handle_; }
|
|
|
|
bool GetOwnValue() const { return own_value_; }
|
|
|
|
|
|
|
|
void Reset() {
|
|
|
|
ReleaseResource();
|
|
|
|
ResetFields();
|
|
|
|
}
|
|
|
|
|
|
|
|
void TransferTo(Cleanable* cleanable) {
|
|
|
|
if (cleanable) {
|
|
|
|
if (cache_handle_ != nullptr) {
|
|
|
|
assert(cache_ != nullptr);
|
|
|
|
cleanable->RegisterCleanup(&ReleaseCacheHandle, cache_, cache_handle_);
|
|
|
|
} else if (own_value_) {
|
|
|
|
cleanable->RegisterCleanup(&DeleteValue, value_, nullptr);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ResetFields();
|
|
|
|
}
|
|
|
|
|
Refactor to avoid confusing "raw block" (#10408)
Summary:
We have a lot of confusing code because of mixed, sometimes
completely opposite uses of of the term "raw block" or "raw contents",
sometimes within the same source file. For example, in `BlockBasedTableBuilder`,
`raw_block_contents` and `raw_size` generally referred to uncompressed block
contents and size, while `WriteRawBlock` referred to writing a block that
is already compressed if it is going to be. Meanwhile, in
`BlockBasedTable`, `raw_block_contents` either referred to a (maybe
compressed) block with trailer, or a maybe compressed block maybe
without trailer. (Note: left as follow-up work to use C++ typing to
better sort out the various kinds of BlockContents.)
This change primarily tries to apply some consistent terminology around
the kinds of block representations, avoiding the unclear "raw". (Any
meaning of "raw" assumes some bias toward the storage layer or toward
the logical data layer.) Preferred terminology:
* **Serialized block** - bytes that go into storage. For block-based table
(usually the case) this includes the block trailer. WART: block `size` may or
may not include the trailer; need to be clear about whether it does or not.
* **Maybe compressed block** - like a serialized block, but without the
trailer (or no promise of including a trailer). Must be accompanied by a
CompressionType.
* **Uncompressed block** - "payload" bytes that are either stored with no
compression, used as input to compression function, or result of
decompression function.
* **Parsed block** - an in-memory form of a block in block cache, as it is
used by the table reader. Different C++ types are used depending on the
block type (see block_like_traits.h).
Other refactorings:
* Misc corrections/improvements of internal API comments
* Remove a few misleading / unhelpful / redundant comments.
* Use move semantics in some places to simplify contracts
* Use better parameter names to indicate which parameters are used for
outputs
* Remove some extraneous `extern`
* Various clean-ups to `CacheDumperImpl` (mostly unnecessary code)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10408
Test Plan: existing tests
Reviewed By: akankshamahajan15
Differential Revision: D38172617
Pulled By: pdillinger
fbshipit-source-id: ccb99299f324ac5ca46996d34c5089621a4f260c
2022-09-22 18:25:32 +00:00
|
|
|
void SetOwnedValue(std::unique_ptr<T>&& value) {
|
|
|
|
assert(value.get() != nullptr);
|
2019-05-10 18:53:33 +00:00
|
|
|
|
Refactor to avoid confusing "raw block" (#10408)
Summary:
We have a lot of confusing code because of mixed, sometimes
completely opposite uses of of the term "raw block" or "raw contents",
sometimes within the same source file. For example, in `BlockBasedTableBuilder`,
`raw_block_contents` and `raw_size` generally referred to uncompressed block
contents and size, while `WriteRawBlock` referred to writing a block that
is already compressed if it is going to be. Meanwhile, in
`BlockBasedTable`, `raw_block_contents` either referred to a (maybe
compressed) block with trailer, or a maybe compressed block maybe
without trailer. (Note: left as follow-up work to use C++ typing to
better sort out the various kinds of BlockContents.)
This change primarily tries to apply some consistent terminology around
the kinds of block representations, avoiding the unclear "raw". (Any
meaning of "raw" assumes some bias toward the storage layer or toward
the logical data layer.) Preferred terminology:
* **Serialized block** - bytes that go into storage. For block-based table
(usually the case) this includes the block trailer. WART: block `size` may or
may not include the trailer; need to be clear about whether it does or not.
* **Maybe compressed block** - like a serialized block, but without the
trailer (or no promise of including a trailer). Must be accompanied by a
CompressionType.
* **Uncompressed block** - "payload" bytes that are either stored with no
compression, used as input to compression function, or result of
decompression function.
* **Parsed block** - an in-memory form of a block in block cache, as it is
used by the table reader. Different C++ types are used depending on the
block type (see block_like_traits.h).
Other refactorings:
* Misc corrections/improvements of internal API comments
* Remove a few misleading / unhelpful / redundant comments.
* Use move semantics in some places to simplify contracts
* Use better parameter names to indicate which parameters are used for
outputs
* Remove some extraneous `extern`
* Various clean-ups to `CacheDumperImpl` (mostly unnecessary code)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10408
Test Plan: existing tests
Reviewed By: akankshamahajan15
Differential Revision: D38172617
Pulled By: pdillinger
fbshipit-source-id: ccb99299f324ac5ca46996d34c5089621a4f260c
2022-09-22 18:25:32 +00:00
|
|
|
if (UNLIKELY(value_ == value.get() && own_value_)) {
|
2019-05-10 18:53:33 +00:00
|
|
|
assert(cache_ == nullptr && cache_handle_ == nullptr);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Reset();
|
|
|
|
|
Refactor to avoid confusing "raw block" (#10408)
Summary:
We have a lot of confusing code because of mixed, sometimes
completely opposite uses of of the term "raw block" or "raw contents",
sometimes within the same source file. For example, in `BlockBasedTableBuilder`,
`raw_block_contents` and `raw_size` generally referred to uncompressed block
contents and size, while `WriteRawBlock` referred to writing a block that
is already compressed if it is going to be. Meanwhile, in
`BlockBasedTable`, `raw_block_contents` either referred to a (maybe
compressed) block with trailer, or a maybe compressed block maybe
without trailer. (Note: left as follow-up work to use C++ typing to
better sort out the various kinds of BlockContents.)
This change primarily tries to apply some consistent terminology around
the kinds of block representations, avoiding the unclear "raw". (Any
meaning of "raw" assumes some bias toward the storage layer or toward
the logical data layer.) Preferred terminology:
* **Serialized block** - bytes that go into storage. For block-based table
(usually the case) this includes the block trailer. WART: block `size` may or
may not include the trailer; need to be clear about whether it does or not.
* **Maybe compressed block** - like a serialized block, but without the
trailer (or no promise of including a trailer). Must be accompanied by a
CompressionType.
* **Uncompressed block** - "payload" bytes that are either stored with no
compression, used as input to compression function, or result of
decompression function.
* **Parsed block** - an in-memory form of a block in block cache, as it is
used by the table reader. Different C++ types are used depending on the
block type (see block_like_traits.h).
Other refactorings:
* Misc corrections/improvements of internal API comments
* Remove a few misleading / unhelpful / redundant comments.
* Use move semantics in some places to simplify contracts
* Use better parameter names to indicate which parameters are used for
outputs
* Remove some extraneous `extern`
* Various clean-ups to `CacheDumperImpl` (mostly unnecessary code)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10408
Test Plan: existing tests
Reviewed By: akankshamahajan15
Differential Revision: D38172617
Pulled By: pdillinger
fbshipit-source-id: ccb99299f324ac5ca46996d34c5089621a4f260c
2022-09-22 18:25:32 +00:00
|
|
|
value_ = value.release();
|
2019-05-10 18:53:33 +00:00
|
|
|
own_value_ = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void SetUnownedValue(T* value) {
|
|
|
|
assert(value != nullptr);
|
|
|
|
|
|
|
|
if (UNLIKELY(value_ == value && cache_ == nullptr &&
|
|
|
|
cache_handle_ == nullptr && !own_value_)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Reset();
|
|
|
|
|
|
|
|
value_ = value;
|
|
|
|
assert(!own_value_);
|
|
|
|
}
|
|
|
|
|
|
|
|
void SetCachedValue(T* value, Cache* cache, Cache::Handle* cache_handle) {
|
|
|
|
assert(cache != nullptr);
|
|
|
|
assert(cache_handle != nullptr);
|
|
|
|
|
|
|
|
if (UNLIKELY(value_ == value && cache_ == cache &&
|
|
|
|
cache_handle_ == cache_handle && !own_value_)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
Reset();
|
|
|
|
|
|
|
|
value_ = value;
|
|
|
|
cache_ = cache;
|
|
|
|
cache_handle_ = cache_handle;
|
|
|
|
assert(!own_value_);
|
|
|
|
}
|
|
|
|
|
2021-06-18 16:35:03 +00:00
|
|
|
void UpdateCachedValue() {
|
|
|
|
assert(cache_ != nullptr);
|
|
|
|
assert(cache_handle_ != nullptr);
|
|
|
|
|
|
|
|
value_ = static_cast<T*>(cache_->Value(cache_handle_));
|
|
|
|
}
|
|
|
|
|
|
|
|
bool IsReady() {
|
|
|
|
if (!own_value_) {
|
|
|
|
assert(cache_ != nullptr);
|
|
|
|
assert(cache_handle_ != nullptr);
|
|
|
|
return cache_->IsReady(cache_handle_);
|
|
|
|
}
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2022-10-25 18:50:38 +00:00
|
|
|
private:
|
|
|
|
void ReleaseResource() noexcept {
|
|
|
|
if (LIKELY(cache_handle_ != nullptr)) {
|
|
|
|
assert(cache_ != nullptr);
|
|
|
|
cache_->Release(cache_handle_);
|
|
|
|
} else if (own_value_) {
|
|
|
|
delete value_;
|
|
|
|
}
|
|
|
|
}
|
Meta-internal folly integration with F14FastMap (#9546)
Summary:
Especially after updating to C++17, I don't see a compelling case for
*requiring* any folly components in RocksDB. I was able to purge the existing
hard dependencies, and it can be quite difficult to strip out non-trivial components
from folly for use in RocksDB. (The prospect of doing that on F14 has changed
my mind on the best approach here.)
But this change creates an optional integration where we can plug in
components from folly at compile time, starting here with F14FastMap to replace
std::unordered_map when possible (probably no public APIs for example). I have
replaced the biggest CPU users of std::unordered_map with compile-time
pluggable UnorderedMap which will use F14FastMap when USE_FOLLY is set.
USE_FOLLY is always set in the Meta-internal buck build, and a simulation of
that is in the Makefile for public CI testing. A full folly build is not needed, but
checking out the full folly repo is much simpler for getting the dependency,
and anything else we might want to optionally integrate in the future.
Some picky details:
* I don't think the distributed mutex stuff is actually used, so it was easy to remove.
* I implemented an alternative to `folly::constexpr_log2` (which is much easier
in C++17 than C++11) so that I could pull out the hard dependencies on
`ConstexprMath.h`
* I had to add noexcept move constructors/operators to some types to make
F14's complainUnlessNothrowMoveAndDestroy check happy, and I added a
macro to make that easier in some common cases.
* Updated Meta-internal buck build to use folly F14Map (always)
No updates to HISTORY.md nor INSTALL.md as this is not (yet?) considered a
production integration for open source users.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/9546
Test Plan:
CircleCI tests updated so that a couple of them use folly.
Most internal unit & stress/crash tests updated to use Meta-internal latest folly.
(Note: they should probably use buck but they currently use Makefile.)
Example performance improvement: when filter partitions are pinned in cache,
they are tracked by PartitionedFilterBlockReader::filter_map_ and we can build
a test that exercises that heavily. Build DB with
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench -benchmarks=fillrandom -num=10000000 -disable_wal=1 -write_buffer_size=30000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters
```
and test with (simultaneous runs with & without folly, ~20 times each to see
convergence)
```
TEST_TMPDIR=/dev/shm/rocksdb ./db_bench_folly -readonly -use_existing_db -benchmarks=readrandom -num=10000000 -bloom_bits=16 -compaction_style=2 -fifo_compaction_max_table_files_size_mb=10000 -fifo_compaction_allow_compaction=0 -partition_index_and_filters -duration=40 -pin_l0_filter_and_index_blocks_in_cache
```
Average ops/s no folly: 26229.2
Average ops/s with folly: 26853.3 (+2.4%)
Reviewed By: ajkr
Differential Revision: D34181736
Pulled By: pdillinger
fbshipit-source-id: ffa6ad5104c2880321d8a1aa7187e00ab0d02e94
2022-04-13 14:34:01 +00:00
|
|
|
|
2022-10-25 18:50:38 +00:00
|
|
|
void ResetFields() noexcept {
|
|
|
|
value_ = nullptr;
|
|
|
|
cache_ = nullptr;
|
|
|
|
cache_handle_ = nullptr;
|
|
|
|
own_value_ = false;
|
|
|
|
}
|
2019-05-10 18:53:33 +00:00
|
|
|
|
|
|
|
static void ReleaseCacheHandle(void* arg1, void* arg2) {
|
|
|
|
Cache* const cache = static_cast<Cache*>(arg1);
|
|
|
|
assert(cache);
|
|
|
|
|
|
|
|
Cache::Handle* const cache_handle = static_cast<Cache::Handle*>(arg2);
|
|
|
|
assert(cache_handle);
|
|
|
|
|
|
|
|
cache->Release(cache_handle);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void DeleteValue(void* arg1, void* /* arg2 */) {
|
|
|
|
delete static_cast<T*>(arg1);
|
|
|
|
}
|
|
|
|
|
2022-10-25 18:50:38 +00:00
|
|
|
private:
|
2019-05-10 18:53:33 +00:00
|
|
|
T* value_ = nullptr;
|
|
|
|
Cache* cache_ = nullptr;
|
|
|
|
Cache::Handle* cache_handle_ = nullptr;
|
|
|
|
bool own_value_ = false;
|
|
|
|
};
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|