feat(malloc_utils): add mimalloc and tcmalloc allocator feature flags

[0xMars42]

Closes #8840

Adds mimalloc and tcmalloc feature flags to malloc_utils, lighthouse, and lcli crates.

Usage

cargo build --release -p lighthouse --features mimalloc
cargo build --release -p lighthouse --features tcmalloc

mimalloc/tcmalloc override jemalloc via cfg guards (same pattern as sysmalloc), so --no-default-features is not needed despite jemalloc being hardcoded in the binary deps.

Both features are unix-only enabling them on Windows produces a compile_error. Enabling both simultaneously also produces a compile_error.

Benchmarks

lcli transition-blocks on a recent mainnet finalized block (10 runs, --exclude-cache-builds --exclude-post-block-thc):

Allocator	Median	Min	Max
jemalloc	1001ms	982ms	1051ms
mimalloc	1002ms	970ms	1171ms
tcmalloc	1066ms	1041ms	1191ms

jemalloc and mimalloc are effectively identical on block processing. tcmalloc is ~6% slower. These numbers only cover transition-blocks though live node testing with sustained load and varying allocation patterns could show different results.

Changes

• common/malloc_utils/Cargo.toml add mimalloc + tcmalloc optional deps and features
• common/malloc_utils/src/lib.rs conditional compilation for new allocators, compile_error guards for invalid combinations
• common/malloc_utils/src/mimalloc_alloc.rs new #[global_allocator] module
• common/malloc_utils/src/tcmalloc_alloc.rs new #[global_allocator] module
• lighthouse/Cargo.toml expose mimalloc/tcmalloc features
• lcli/Cargo.toml expose mimalloc/tcmalloc features

Allocator metrics for mimalloc/tcmalloc are stubbed out can be filled in as a follow-up once we decide which allocator to invest in.

[cla-assistant]

All committers have signed the CLA.

[michaelsproul]

Please familiarise yourself with our policy regarding AI contributions (currently in review but likely to be merged very soon):

• Update contribution guidlines regarding LLM usage #8879

[michaelsproul]

Looks like a good starting point.

I think there are probably a few more considerations to help us choose between tcmalloc and mimalloc, like:

• Node performance: we should deploy some long-running nodes with both allocators and observe their performance
• Debug tooling: which allocator has better tools for debugging, e.g. live allocation counts, heap introspection, etc.
• Compile time: does one of the two compile substantially faster?

[michaelsproul]

Interesting that modern tcmalloc doesn't support macOS. That might be a reason to go deeper on mimalloc.

It could also be that the macOS system allocator is fine for Lighthouse. It's mostly the glibc allocator we want to avoid.

[0xMars42]

Interesting that modern tcmalloc doesn't support macOS. That might be a reason to go deeper on mimalloc.

It could also be that the macOS system allocator is fine for Lighthouse. It's mostly the glibc allocator we want to avoid.

Thanks for the great feedback! Don't hesitate if you'd like me to adjust anything else.