Thinking to reactivate wee_alloc

announcements
1

I am thinking to reactivate wee_alloc.

wee_alloc is a Rust #[global_allocator], and its whole pitch is tiny Wasm binaries. The README advertises under 1 KiB of uncompressed Wasm. Under the hood it is a simple first-fit free-list allocator: allocation is O(n), deallocation O(1). It also ships Unix, Windows, and static-array backends in addition to the Wasm backend.

As of April 2026, upstream is not just quiet, it is over. The latest published version is 0.4.5 from August 22, 2019. RustSec marked the crate unmaintained in September 2022 and warned that open memory-leak issues may make it unsuitable for production use. The GitHub repository was archived and made read-only on August 25, 2025 as part of the broader sunsetting of the rustwasm GitHub organization

Despite of long talks how it should not be used, there are still about 8000 daily downloads. There are some bug reports as well but it is possible to work on them.

So far I made it to build with modern tools, set up the CI pipeline again, advanced the versions of dependences and started looking into existing issues, there are 21 in total. Will be seen.

The project repository can be found at wee_alloc_bw. This is relatively specific crate so an announcement likely needs to be posted to get noticed that somebody is doing something with it.

7 Likes
2

We released 1.0.1 where we made quite many changes:

  • Fix extra_assertions free-cell poisoning helpers to use raw allocation pointers for trailing payload access, avoiding Miri-reported UB from deriving tail writes through &FreeCell references.
  • Fix additional strict-provenance/Miri issues in intrusive free-list pointer handling by replacing integer-pointer tag manipulation with pointer address APIs and by keeping allocation/free/split paths on raw allocation-origin pointers end-to-end.
  • Fixed long-lived fragmentation by implementing an eager splice-out strategy for deallocation, replacing the delayed-merge mechanism for the right neighbor.
  • Fix a large-allocation free-list traversal bug that could leak memory when overlapping large allocations were freed and later reallocated instead of reusing both freed blocks 106
  • Fix an integer overflow in LargeAllocPolicy::new_cell_for_free_list that caused incorrect memory allocation and potential memory leaks when requesting very large sizes (e.g., usize::MAX - 8) 100
  • Added WeeAlloc::stats() and AllocStats to allow monitoring the allocator's internal state (free list counts and total free bytes), gated behind the default-off instrumentation feature.
  • Investigated memory leak cases listed in 106, but seems it does not leak the way described. Maybe this was fixed.

Further activities on this project will depend on the level of interest.

5 Likes
3

There are a few alternatives to wee_alloc nowadays:

Any idea how wee_alloc compares?

Twocents: if wee_alloc doesn't have any significant advantages over these, I think it may be best to:

  1. Mention alternatives in the README
  2. Ask the original wee_alloc maintainers to publish your version as a final release
  3. Consider it deprecated or at least let it coast in "security patches only" mode

In other words I'm not sure it's worth much effort keeping the project alive. It doesn't hurt to ship a version that patches the soundness bug to make those downloads slightly less concerning though, and if people aren't switching because they don't know of alternatives then making that more discoverable will help.

If you're planning on rebooting it as a full-fledged project with advantages then of course that's a different thing entirely!

1 Like