Hi, I have a proposed change swapping the jemallocator dependency to the tikv-jemallocator crate. This is because the jemallocator crate is a mirror of tikv-jemallocator, but significantly older.
This upgrades jemalloc from 5.2.1 (or older?) to 5.3.1, which comes with a bunch of bug fixes and performance enhancements. Code is partially adapted from store: enable rocksdb/jemalloc feature - Pull Request #1577 - stalwartlabs/stalwart - GitHub , and this change works towards fixing some issues on NixOS related to RocksDB not using the same allocator as Stalwart.
I’m making this post per the new contributor policy’s requirements for becoming a vouched contributor first. This contribution (and this post) is made with no AI assistance or AI generated content.
I also wanted to inquire as to where I can find the actual text of the contributor license agreement; the FLA 2.0 seems to have a chooser that changes the text of the agreement, so I don’t know what specific version of the FLA is actually being signed for Stalwart. If I’m missing an obvious link to the actual text, please let me know/send it over.
Thanks for the suggestion, we swapped jemallocator for tikv-jemallocator 0.7 in both the main binary and the test crate, and you’re credited in the CHANGELOG for 0.16.17.
One comment about the version numbers, we weren’t on 5.2.1. The old jemallocator 0.5.4 pulls jemalloc-sys 0.5.4+5.3.0-patched, so we were already on jemalloc 5.3.0. The real gain from the swap is 5.3.0 to 5.3.1, plus getting off a crate name that hasn’t seen a release since July 2023 and onto the one tikv actually maintains.
On the RocksDB side, I looked into whether we could also close the allocator split you mentioned, and unfortunately it’s blocked. librocksdb-sys requires tikv-jemalloc-sys ^0.6, both in the version we currently resolve and on master. Since that crate declares links = "jemalloc", Cargo refuses to build two semver-incompatible copies in the same graph, so enabling the rocksdb/jemalloc feature alongside tikv-jemallocator 0.7 is a hard build error rather than something we can work around with a patch or a feature flag.
That leaves an either/or for now. We can have jemalloc 5.3.1 for the server but leave RocksDB on the system allocator, or pin back to tikv-jemallocator 0.6.1 and unify the allocator immediately, but at 5.3.0, which is the same jemalloc we were already running. We went with 0.7, on the grounds that the version bump is a real improvement we get today, while the unification only helps a subset of setups and is a one-line change once the upstream PR lands.