Opt-in rusty_alloc feature alongside mimalloc

The value of integrating

Demikernel is currently pulling in mimalloc for allocation; Cargo.toml pins mimalloc = "^0.1.43".

If you added rusty_alloc as a feature, malloc on the dataplane would stop needing a C compiler as a roommate. Same mimalloc v2 architecture, in pure Rust, empty C tree. Catnap, catnip, catpowder and the syscall API stay as they are. The rusty_alloc README measures the free fast path at 21 instructions against mimalloc's 25.

Not asking you to change the default; this would sit behind a feature flag.

How to integrate

An off-by-default Cargo feature, so existing users see no difference:

[features]
alloc-rusty = ["dep:rusty_alloc-api"]

[dependencies]
rusty_alloc-api = { version = "1.1.6", optional = true }

When the flag is on, the surface from the rusty_alloc README is:

use rusty_alloc_api::RustyAlloc;

#[global_allocator]
static ALLOC: RustyAlloc = RustyAlloc;

Mimalloc stays the default. Flip alloc-rusty on in CI, compare on your own corpus, and drop the feature with one line if it does not hold up. The LibOS API, tests, and output stay the same.

Remade With Rust & MATA

We are rebuilding the stack in safe Rust — codecs, parsers, compression, identity, storage — so projects can drop C dependencies without giving up performance. The rest of the org lives at https://github.com/Remade-With-Rust if anything else fits the build. If this is a poor fit, close the issue; that is a perfectly good outcome.

• x.com/farmer_timmm

Start with Cargo.toml, especially the existing mimalloc dependency and feature definitions, then review the rusty_alloc README surface described in the issue. Enable the optional dependency behind alloc-rusty and add an opt-in CI build or comparison; done means the default remains mimalloc and the LibOS API, tests, and output are unchanged.