Use jemalloc as the daemon's memory allocator

A full table from several neighbors means millions of small, long-lived
allocations that are replaced as routes change. jemalloc keeps the
resident size of such a workload closer to what is in use than the
system allocator does, glibc's in particular, and does not depend on
the C library the binary is linked with. Not on MSVC, which jemalloc
does not support.

Building now needs a C compiler and make; the installation page says
so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

bin/bgp/Cargo.toml

@@ -18,5 +18,10 @@ tokio.workspace      = true
 tracing.workspace    = true
 tracing-subscriber.workspace = true
 
+# jemalloc does not build with the MSVC toolchain; there the system
+# allocator is used.
+[target.'cfg(not(target_env = "msvc"))'.dependencies]
+tikv-jemallocator.workspace = true
+
 [lints]
 workspace = true

bin/bgp/src/main.rs

@@ -13,6 +13,13 @@ use crate::logging::LoggingArgs;
 
 mod logging;
 
+// jemalloc, rather than the C library's allocator. Taking in a full table
+// allocates from many threads at once, which glibc's allocator handles
+// less well and musl's, in the static build, much worse.
+#[cfg(not(target_env = "msvc"))]
+#[global_allocator]
+static ALLOCATOR: tikv_jemallocator::Jemalloc = tikv_jemallocator::Jemalloc;
+
 /// A BGP speaker.
 #[derive(Parser, Debug)]
 #[command(version)]