The primary change introduced in this commit is partitioning of
the `TaggedCache`, with each partition being indepedent of each
other, making it possible to potentially perform multiple cache
operations in parallel. In particular, the `sweep` operation is
now parallelized by default on systems with at least four cores
present.
The `TaggedCache` could also be instantiated in 'key-only' mode
which complicated the interface significantly but was only used
by a single consumer (the `FullBelowCache`). This commit splits
the 'key-only' functionality of `TaggedCache`, and incorporates
directly into `FullBelowCache`, resulting in simple and cleaner
interfaces for both `TaggedCache` and `FullBelowCache` but at a
cost: some code duplication.
Lastly, this commit includes a medley of changes, including the
restructuring of `Transaction`, reducing its size by 48 bytes.
This commit cleans up and modernizes the JobQueue but does not change
the queueing logic. It focuses on simplifying the code by eliminating
awkward code constructs, like "invalid jobs" and the need for default
constructors.
It leverages modern C++ to initialize tables and data structures at
compile time and replaces `std:map` instances with directly indexed
arrays.
Lastly, it restructures the load tracking infrastructure and reduces
the need for dynamic memory allocations by supporting move semantics
and value types.
The existing thread pool code uses several layers of indirection which
uses a custom lock-free stack, and offers functionality that supports
features that are never used (e.g. the ability to dynamically adjust
the number of threads in the pool).
This refactoring aims to simplify the code, making it easier to reason
about (although lock-free multi-threaded code is always tricky) what
is happening, and reduce the latency of the thread pool internals.
In the release notes (current and historical), there is a link to the
`Builds` directory. By creating `Builds/README.md` with a link to
`BUILD.md`, it is easier to find the build instructions.
Make it easy for projects to depend on libxrpl by adding an `ALIAS`
target named `xrpl::libxrpl` for projects to link.
The name was chosen because:
* The current library target is named `xrpl_core`. There is no other
"non-core" library target against which we need to distinguish the
"core" library. We only export one library target, and it should just
be named after the project to keep things simple and predictable.
* Underscores in target or library names are generally discouraged.
* Every target exported in CMake should be prefixed with the project
name.
By adding an `ALIAS` target, existing consumers who use the `xrpl_core`
target will not be affected.
* In the future, there can be a migration plan to make `xrpl_core` the
`ALIAS` target (and `libxrpl` the "real" target, which will affect the
filename of the compiled binary), and eventually remove it entirely.
Also:
* Fix the Conan recipe so that consumers using Conan import a target
named `xrpl::libxrpl`. This way, every consumer can use the same
instructions.
* Document the two easiest methods to depend on libxrpl. Both have been
tested.
* See #4443.
* Remove obsolete build instructions.
* By using Conan, builders can choose which dependencies specifically to
build and link as shared objects.
* Refactor the build instructions based on the plan in #4433.
When writing objects to the NodeStore, we need to convert them from
the in-memory format to the binary format used by the node store.
The conversion is handled by the `EncodedBlob` class, which is only
instantiated on the stack. Coupled with the fact that most objects
are under 1024 bytes in size, this presents an opportunity to elide
a memory allocation in a critical path.
This commit also simplifies the interface of `EncodedBlob` and
eliminates a subtle corner case that could result in dangling
pointers.
These changes are not expected to cause a significant reduction in
memory usage. The change avoids the use of a `std::shared_ptr` when
unnecessary and tries to use stack-based memory allocation instead
of the heap whenever possible.
This is a net gain both in terms of memory usage (lower
fragmentation) and performance (less work to do at runtime).
Introduces a conanfile.py (and a Conan recipe for RocksDB) to enable building the package with Conan, choosing more recent default versions of dependencies. It removes almost all of the CMake build files related to dependencies, and the configurations for Travis CI and GitLab CI. A new set of cross-platform build instructions are written in BUILD.md.
Includes example GitHub Actions workflow for each of Linux, macOS, Windows.
* Test on macos-12
We use the <concepts> library which was not added to Apple Clang until
version 13.1.6. The default Clang on macos-11 (the sometimes current
version of macos-latest) is 13.0.0, and the default Clang on macos-12 is
14.0.0.
Closes#4223.
* Removed a reference to the default number of workers varying based on whether a node has validation enabled. Workers default to the number of processor cores + 2: https://github.com/ripple/rippled/blob/develop/src/ripple/core/impl/JobQueue.cpp#L166
* Protobuf v2 and Ubuntu 16.04 are no longer supported.
* Updated protobuf version as v3 is now supported, fixed typos, automatically sent number of processors when building boost & rippled.
