The Wasm-Enabled, Elfin Allocator



The Wasm-Enabled, Elfin Allocator

Build Status Build Status version Download docs

API Docs | Contributing | Chat

Built with 🦀 🕸 by The Rust and WebAssembly Working Group


wee_alloc: The Wasm-Enabled, Elfin Allocator.

  • Elfin, i.e. small: Generates less than a kilobyte of uncompressed WebAssembly code. Doesn't pull in the heavy panicking or formatting infrastructure. wee_alloc won't bloat your .wasm download size on the Web.

  • WebAssembly enabled: Designed for the wasm32-unknown-unknown target and #![no_std].

wee_alloc is focused on targeting WebAssembly, producing a small .wasm code size, and having a simple, correct implementation. It is geared towards code that makes a handful of initial dynamically sized allocations, and then performs its heavy lifting without any further allocations. This scenario requires some allocator to exist, but we are more than happy to trade allocation performance for small code size. In contrast, wee_alloc would be a poor choice for a scenario where allocation is a performance bottleneck.

Although WebAssembly is the primary target, wee_alloc also has an mmap based implementation for unix systems, a VirtualAlloc implementation for Windows, and a static array-based backend for OS-independent environments. This enables testing wee_alloc, and code using wee_alloc, without a browser or WebAssembly engine.

wee_alloc compiles on stable Rust 1.33 and newer.

Using wee_alloc as the Global Allocator

extern crate wee_alloc;

// Use `wee_alloc` as the global allocator.
static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;

cargo Features

  • size_classes: On by default. Use size classes for smaller allocations to provide amortized O(1) allocation for them. Increases uncompressed .wasm code size by about 450 bytes (up to a total of ~1.2K).

  • extra_assertions: Enable various extra, expensive integrity assertions and defensive mechanisms, such as poisoning freed memory. This incurs a large runtime overhead. It is useful when debugging a use-after-free or wee_alloc itself.

  • static_array_backend: Force the use of an OS-independent backing implementation with a global maximum size fixed at compile time. Suitable for deploying to non-WASM/Unix/Windows #![no_std] environments, such as on embedded devices with esoteric or effectively absent operating systems. The size defaults to 32 MiB (33554432 bytes), and may be controlled at build-time by supplying an optional environment variable to cargo, WEE_ALLOC_STATIC_ARRAY_BACKEND_BYTES. Note that this feature requires nightly Rust.

  • nightly: Enable usage of nightly-only Rust features, such as implementing the Alloc trait (not to be confused with the stable GlobalAlloc trait!)

Implementation Notes and Constraints

  • wee_alloc imposes two words of overhead on each allocation for maintaining its internal free lists.

  • Deallocation is an O(1) operation.

  • wee_alloc will never return freed pages to the WebAssembly engine / operating system. Currently, WebAssembly can only grow its heap, and can never shrink it. All allocated pages are indefinitely kept in wee_alloc's internal free lists for potential future allocations, even when running on unix targets.

  • wee_alloc uses a simple, first-fit free list implementation. This means that allocation is an O(n) operation.

    Using the size_classes feature enables extra free lists dedicated to small allocations (less than or equal to 256 words). The size classes' free lists are populated by allocating large blocks from the main free list, providing amortized O(1) allocation time. Allocating from the size classes' free lists uses the same first-fit routines that allocating from the main free list does, which avoids introducing more code bloat than necessary.

Finally, here is a diagram giving an overview of wee_alloc's implementation:

| WebAssembly Engine / Operating System                                        |
                   | 64KiB Pages
| Main Free List                                                               |
|                                                                              |
|          +------+     +------+     +------+     +------+                     |
| Head --> | Cell | --> | Cell | --> | Cell | --> | Cell | --> ...             |
|          +------+     +------+     +------+     +------+                     |
|                                                                              |
                   |                                    |            ^
                   |                                    |            |
                   | Large Blocks                       |            |
                   |                                    |            |
                   V                                    |            |
+---------------------------------------------+         |            |
| Size Classes                                |         |            |
|                                             |         |            |
|             +------+     +------+           |         |            |
| Head(1) --> | Cell | --> | Cell | --> ...   |         |            |
|             +------+     +------+           |         |            |
|                                             |         |            |
|             +------+     +------+           |         |            |
| Head(2) --> | Cell | --> | Cell | --> ...   |         |            |
|             +------+     +------+           |         |            |
|                                             |         |            |
| ...                                         |         |            |
|                                             |         |            |
|               +------+     +------+         |         |            |
| Head(256) --> | Cell | --> | Cell | --> ... |         |            |
|               +------+     +------+         |         |            |
|                                             |         |            |
+---------------------------------------------+         |            |
                      |            ^                    |            |
                      |            |                    |            |
          Small       |      Small |        Large       |      Large |
          Allocations |      Frees |        Allocations |      Frees |
                      |            |                    |            |
                      |            |                    |            |
                      |            |                    |            |
                      |            |                    |            |
                      |            |                    |            |
                      V            |                    V            |
| User Application                                                             |


Licensed under the Mozilla Public License 2.0.


Permissions of this weak copyleft license are conditioned on making available source code of licensed files and modifications of those files under the same license (or in certain cases, one of the GNU licenses). Copyright and license notices must be preserved. Contributors provide an express grant of patent rights. However, a larger work using the licensed work may be distributed under different terms and without source code for files added in the larger work.


See for hacking!

  • Work in stable rust

    Work in stable rust


    Now that GlobalAlloc is in stable Rust, we should cfg-off the Alloc implementation such that wee_alloc can be used as a global allocator in stable rust.


    Stabilize all the things!


    Will need to introduce a nightly cargo feature to turn on the Alloc implementation. Since the GlobalAlloc implementation proxies to the Alloc implementation, we will need to do some light refactoring to move those proxied methods into normal, non-trait methods on WeeAlloc.

    This could be a good issue for someone who wants to dive into the code base for the first time!

    enhancement assigned 
    opened by fitzgen 17
  • Move into separate crate?

    Move into separate crate?

    Maybe a weird idea, but what do you think about


    Move to separate crate and publish it on


    I came up with that idea when I was working on wasmi. I noticed that Pages→Bytes and Bytes→Pages are quite common thing that people want to do, when working with parity-wasm/wasmi. Example here and there.


    I think just taking and moving it into another crate will be enough. I'm ready to take this if we agree if this idea is worth it.

    enhancement assigned 
    opened by pepyakin 17
  • Build (nightly) fails: error[E0152]: duplicate lang item found: `panic_fmt`.

    Build (nightly) fails: error[E0152]: duplicate lang item found: `panic_fmt`.


    Include a sentence or two summarizing the bug.

    Does not build with rust nightly

    Steps to Reproduce

    $ cargo build
    error[E0152]: duplicate lang item found: `panic_fmt`.
      --> example/src/
    22 | / extern "C" fn panic_fmt(_args: ::core::fmt::Arguments, _file: &'static str, _line: u32) -> ! {
    23 | |     unsafe {
    24 | |         ::core::intrinsics::abort();
    25 | |     }
    26 | | }
       | |_^
       = note: first defined in crate `std`.
    error[E0152]: duplicate lang item found: `oom`.
      --> example/src/
    31 | / extern "C" fn oom() -> ! {
    32 | |     unsafe {
    33 | |         ::core::intrinsics::abort();
    34 | |     }
    35 | | }
       | |_^
       = note: first defined in crate `std`.
    error: aborting due to 2 previous errors
    For more information about this error, try `rustc --explain E0152`.
    error: Could not compile `wee_alloc_example`.
    $ /usr/bin/ld --version
    GNU ld (GNU Binutils for Ubuntu) 2.26.1
    Copyright (C) 2015 Free Software Foundation, Inc.

    Same with rustc nightly 2018-04-27 and 2018-05-09

    opened by MarkSwanson 7
  • Support allocations with alignment greater than a word

    Support allocations with alignment greater than a word


    When I create a Vec of Enums that have a u64 field on them I get the following error: RuntimeError: unreachable

    Steps to Reproduce

    • git clone
    • cd wee_alloc_vec_of_enums_bug
    • cargo rustc --target wasm32-unknown-unknown --lib -- -O && node run.js

    Actual Results

        Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
    (node:6108) UnhandledPromiseRejectionWarning: RuntimeError: unreachable
        at run (wasm-function[7]:1)
        at run (/Users/masonf/src/wee_alloc_vec_of_enums_bug/run.js:20:20)
        at <anonymous>
        at process._tickCallback (internal/process/next_tick.js:160:7)
        at Function.Module.runMain (module.js:703:11)
        at startup (bootstrap_node.js:193:16)
        at bootstrap_node.js:617:3
    (node:6108) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 1)
    (node:6108) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

    Expected Results

    Finished dev [unoptimized + debuginfo] target(s) in 0.0 secs
    opened by masonforest 7
  • Add a quicli script to trace malloc and frees and turn them into test inputs!

    Add a quicli script to trace malloc and frees and turn them into test inputs!

    This introduces a script that uses valgrind to trace some program's mallocs and frees, and then it turns those into something that can be used as test/benchmark inputs for wee_alloc.

    cc @alexcrichton; you may also find this useful for the other rust allocators you maintain ;)

    opened by fitzgen 6
  • Proposed fix to enforce byte alignment for static_array_backend feature

    Proposed fix to enforce byte alignment for static_array_backend feature

    Problem statement

    The wee_alloc implementation of the static_array_backend feature erroneously causes an out-of-memory error. The context where the problem arises is in compilation for a bare-metal embedded system (OS independent, target is something like armv7-unknown-linux-gnueabihf), using the static_array_backend feature and assigning wee_alloc as the global allocator.

    The root cause of the resulting error is the implementation of imp_static_array::alloc_pages(). The function creates a pointer to a slice of the SCRATCH_HEAP of the requested size, which is used to create the FreeCell objects that compose the free list. The function does not enforce that the slice pointer maintain any byte boundary alignment, resulting in unaligned FreeCell objects. This ultimately creates an edge case error where allocation fails despite adequate memory left in the SCRATCH_HEAP. The error occurs regardless of the configured static backend array size exported at compile time. Additionally, the failure arises regardless of size policy (e.g. whether or not the size_classes feature is enabled).

    Detailed description of the control flow in which the problem arises

    The problem is immediately detectable by enabling the extra_assertions feature. With this feature enabled, the first call to allocate memory from the free list results in an alignment assertion failure, because as described above, the FreeCell objects created from the SCRATCH_HEAP object do not have the proper alignment. However, when extra_assertions feature is not enabled, the edge case in the example system occurs when the first 256 Kb of the free list are exhausted a.k.a. a full walk of the initial free list results in alloc_with_refill() executing the code branch to create and insert a new FreeCell.

    Upon an allocation request, the allocator attempts to allocate from the SCRATCH_HEAP. This is done via call to the GlobalAlloc trait’s implementation of alloc(), which calls alloc_impl(), which then calls alloc_with_refill() within a function closure passed to self.with_free_list_and_policy_for_size. The alloc_with_refill function first calls alloc_first_fit() which walks the free list to find a FreeCell of adequate size. After the 256 Kb exhaustion point, alloc_first_fit fails to find a FreeCell of adequate size. At this point, the branch for creating and inserting a new FreeCell is executed via calls to new_cell_for_free_list() and insert_into_free_list(). Control flow then returns to alloc_with_refill, which calls alloc_first_fit again, which in turn calls try_alloc() on the newly inserted FreeCell object, which is the point of failure. The checks in try_alloc() assert that the newly inserted FreeCell is large enough to hold the requested allocation size, but that it is not big enough to be split in two. This leads to the final check in try_alloc(), which determines if the FreeCell is appropriately aligned, which, because of how alloc_pages() is implemented for the impl_static_array mod, results in a failure to allocate.

    Steps to reproduce problem

    1. Use the static array backend feature, compiled for a no_std target (e.g. `armv7-unknown-linux-gnueabihf`) and use the default backend array bytes size
    2. Allocate via `alloc::Vec::Vec()` an empty vector of u32s, and then push 65 data to it.
    3. wee_alloc will fail to allocate more heap memory at the attempt to push the 65th u32 to the vector, triggering an oom() error (if the system has one defined) via the method described above

    Proposed problem fix

    To address this error, the imp_static_array::alloc_pages() function should enforce alignment requirements such that pointers to slices of the SCRATCH_HEAP are always aligned to the needed byte boundary. The resulting FreeCell objects will therefore always meet alignment checks, whether or not the extra_assertions feature is enabled.

    opened by nand-nor 5
  • Update rand requirement to 0.5.3

    Update rand requirement to 0.5.3

    Updates the requirements on rand to permit the latest version.


    Sourced from rand's changelog.

    [0.5.3] - 2018-06-26

    Platform support

    • OpenBSD, Bitrig: fix compilation (broken in 0.5.1) (#530)

    [0.5.2] - 2018-06-18

    Platform support

    • Hide OsRng and JitterRng on unsupported platforms (#512; fixes #503).

    [0.5.1] - 2018-06-08

    New distributions

    • Added Cauchy distribution. (#474, #486)
    • Added Pareto distribution. (#495)

    Platform support and OsRng

    • Remove blanket Unix implementation. (#484)
    • Remove Wasm unimplemented stub. (#484)
    • Dragonfly BSD: read from /dev/random. (#484)
    • Bitrig: use getentropy like OpenBSD. (#484)
    • Solaris: (untested) use getrandom if available, otherwise /dev/random. (#484)
    • Emscripten, stdweb: split the read up in chunks. (#484)
    • Emscripten, Haiku: don't do an extra blocking read from /dev/random. (#484)
    • Linux, NetBSD, Solaris: read in blocking mode on first use in fill_bytes. (#484)
    • Fuchsia, CloudABI: fix compilation (broken in Rand 0.5). (#484)

    [0.5.0] - 2018-05-21

    Crate features and organisation

    • Minimum Rust version update: 1.22.0. (#239)
    • Create a separate rand_core crate. (#288)
    • Deprecate rand_derive. (#256)
    • Add prelude (and module reorganisation). (#435)
    • Add log feature. Logging is now available in JitterRng, OsRng, EntropyRng and ReseedingRng. (#246)
    • Add serde1 feature for some PRNGs. (#189)
    • stdweb feature for OsRng support on WASM via stdweb. (#272, #336)

    Rng trait

    • Split Rng in RngCore and Rng extension trait. next_u32, next_u64 and fill_bytes are now part of RngCore. (#265)
    • Add Rng::sample. (#256)
    • Deprecate Rng::gen_weighted_bool. (#308)
    • Add Rng::gen_bool. (#308)
    • Remove Rng::next_f32 and Rng::next_f64. (#273)
    • Add optimized Rng::fill and Rng::try_fill methods. (#247)
    • Deprecate Rng::gen_iter. (#286)
    • Deprecate Rng::gen_ascii_chars. (#279)

    rand_core crate

    • rand now depends on new rand_core crate (#288)
    • RngCore and SeedableRng are now part of rand_core. (#288)
    ... (truncated)

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

    Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

    You can always request more updates by clicking Bump now in your Dependabot dashboard.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

    Additionally, you can set the following in your Dependabot dashboard:

    • Update frequency (including time of day and day of week)
    • Automerge options (never/patch/minor, and dev/runtime dependencies)
    • Pull request limits (per update run and/or open at any time)
    • Out-of-range updates (receive only lockfile updates, if desired)
    • Security updates (receive only security updates, if desired)

    Finally, you can contact us by mentioning @dependabot.

    opened by dependabot-preview[bot] 4
  • Fixed-sized backend for use with atypical targets

    Fixed-sized backend for use with atypical targets

    Hello, wee_alloc team! @fitzgen @pepyakin @DrGoldfire


    This PR expands the usability of wee_alloc for arbitrary #[no_std] targets with a bit of memory lying around.


    The main change is the introduction of a static_array_backend feature that causes wee_alloc to use an implementation that works largely independent of the operating environment capabilities, at the cost of having a completely fixed maximum size, currently 32 megabytes.

    This feature is entirely conditionally compiled, and not present by default, and thus should have no noteworthy burden on extant code capabilities or size.

    Per the CONTRIBUTING guidelines, cargo fmt --all was run on this branch, which caused some nonessential changes to unrelated files.


    This contribution rose out of my desire to apply wee_alloc, a well-tested and actively developed allocator in the context of a non-Unix/WASM/Windows environment.

    I hope that an OS-independent option will also provide other developers a quick way to get wee_alloc up and running for use cases associated with less common operating systems or environments.

    Future Directions

    I could imagine further refinement by using either feature flags, tricky macros, or generics to allow control of the size of the presently-fixed static array backend. Said refinements have been intentionally excluded from this PR in order to keep the complexity down and, more importantly, avoid any impact on the primary use cases. If there is interest, we could expand the backend flexibility in future efforts.

    opened by ZackPierce 4
  • Pull the doubly-linked neighbors list out into its own module

    Pull the doubly-linked neighbors list out into its own module

    This makes it so that the neighbors list, and all of its pointers and their low bits, are abstracted out a little bit. This should help pave the way for using soon.

    Surprisingly, this is also results in something like a 10x speed up on the #[bench]s and a small code size bump. Happy to take the speed up, and unconcerned about the size bump, because this is a stepping stone towards larger, more fundamental refactorings in the future.

    opened by fitzgen 4
  • Fixes allocator to reflect changes in nightly API

    Fixes allocator to reflect changes in nightly API

    Recent changes in nightly broke wee_alloc build. In an attempt to solve the issues I prepared the following PR.

    Unfortunately, not all changes are resolved at the moment, so I would really appreciate any suggestions and comments on the remaining issues.

    Currently there are three of them:

    • [x] definition of unknown language item panic_fmt at example/src/
    • [ ] ~~duplicate lang item found: oom at example/src/
    • [ ] ~~duplicate lang item found: eh_personality at example/src/

    Aside of that, the rest of the code compiles successfully.

    opened by 0x7CFE 3
  • Add compile-time env var sizing of `static_array_backend`

    Add compile-time env var sizing of `static_array_backend`


    Allow the static_array_backend to be optionally sized at compile time by the end user


    A build script has been added to wee_alloc that reads the WEE_ALLOC_STATIC_ARRAY_BACKEND_BYTES environment variable, does some sanitization to be sure it fits in u32, and records the numeric value as UTF8 in a "wee_alloc_static_array_backend_size_bytes.txt" file in the build output directory. This file is directly included in wee_alloc/src/ as the value for SCRATCH_LEN_BYTES.

    This environment variable usage is entirely optional. The default remains the same, at 32 megabytes.


    To allow users with direct knowledge of the memory available on their systems to better fit their use of the static_array_backend feature to the resources at hand.

    opened by ZackPierce 3
  • Is this repo still maintained?

    Is this repo still maintained?


    There's a pretty big bug #106 that sees a lot of projects switch away from using this crate. It hasn't received any comment or apparent attempt at fixing from anyone in the rust wasm org/team in 2 months.

    Also, there has only been 1 commit in the last 3 years. Is this crate still maintained? It looks like @fitzgen is the original author and the other team members are @ZackPierce and @pepyakin.

    Maybe the bug could be mentioned in the readme to raise awareness, so that people don't spend a lot of time debugging something that is not solvable.

    What are alternatives for this crate?

    This crate is quite popular at 2k daily downloads.

    opened by corneliusroemer 5
  • Unbounded Memory Leak

    Unbounded Memory Leak

    Describe the Bug

    Making two large allocations, then dropping them in the order they were allocated leaks memory in wee_alloc, but not in default allocator.

    Steps to Reproduce

    Native code

    1. Clone this branch of my app:
    2. cargo run
    3. GB of memory is consumed per second
    4. Comment out use of wee_alloc global_allocator.
    5. cargo run
    6. Memory use does not increase.


    1. Clone this branch of my app:
    2. npm run serve (runs wasm-pack, npm install and webpack dev server)
    3. go to localhost:8080 in browser
    4. click the button (it's the only thing on the page) to increase heap by 131 MB each time

    Expected Behavior

    Second time allocations are made uses free list.

    Actual Behavior

    Repeated allocations grow heap infinitely.

    Additional Context

    This seems similar to an issue mentioned in #105 Heap size does not increase if using default allocator.

    Rust source for example is just:

    extern crate wee_alloc;
    // Use `wee_alloc` as the global allocator.
    static ALLOC: wee_alloc::WeeAlloc = wee_alloc::WeeAlloc::INIT;
    pub fn leak_test() {
        // This leaks when using wee_alloc
        let a = Box::new([0; 85196]);
        let b = Box::new([0; 80000]);
    fn main() {
        loop {
    opened by CraigMacomber 8
  • Possible allocator memory corruption?

    Possible allocator memory corruption?

    Describe the Bug

    Unfortunately, I'm not sure. Using wee_alloc causes bugs in Bevy, suggesting a bug somewhere in the allocator.

    Steps to Reproduce


    Expected Behavior

    No memory corruption bugs.

    Actual Behavior

    Memory corruption.

    opened by SUPERCILEX 1
  • Update outdated usage instruction regarding

    Update outdated usage instruction regarding "extern crate"

    The README currently specifies to use extern crate wee_alloc;, but this is only needed for Rust 2015 and not for Rust 2018. This is distracting for new Rust users who wonder why this is needed.

    Either remove this usage of extern crate or clearly mark it as only needed for Rust 2015.

    opened by hkBst 0
  • Impossibly large allocations fails but still allocates new memory pages

    Impossibly large allocations fails but still allocates new memory pages

    Describe the Bug

    Allocating usize::MAX - 8 bytes fails but allocates new memory pages every time.

    Steps to Reproduce

    fn cannot_alloc_max_usize_m8() {
        let a = &wee_alloc::WeeAlloc::INIT;
        let layout = Layout::from_size_align(std::usize::MAX - 8, 1)
            .expect("should be able to create a `Layout` with size = std::usize::MAX - 8");
        for _ in 0..10000000 {
            let result = unsafe { a.alloc(layout) };

    Expected Behavior

    The test should complete without causing OOM.

    Actual Behavior

    With debug assertions: thread 'cannot_alloc_max_usize_m8' panicked at 'attempt to add with overflow', .../.cargo/registry/src/

    Without debug assertions: The test allocates tens of gigabytes of memory and eventually gets killed by the kernel.

    opened by yvt 0
Rust and WebAssembly
🦀 + 🕸️ = 💖
Rust and WebAssembly
Wasm runtime written in Rust

Wasm runtime written in Rust

Teppei Fukuda 1 Oct 29, 2021
Wasm video filter booth app written in Rust

Video effect booth written in Rust and WebAssembly Play with it here: Aim I wrote this purely to teach myself

Matt Harrison 75 Nov 21, 2022
A template for kick starting a Rust and WebAssembly project using wasm-pack.

A template for kick starting a Rust and WebAssembly project using wasm-pack.

Haoxi Tan 1 Feb 14, 2022
{Wasm+Rust} Build and animate Conway's Game of Life

A self-guided learning project that includes Rust + Wasm together. Who knows, maybe Typescript and React joins too..

M.Yavuz Yagis 1 Feb 14, 2022
wasmy, easily customize my wasm app

wasmy wasmy, easily customize my wasm app! features Completely shield vm-wasm interaction details Simple and flexible ABI, supports freely adding vm a

henrylee2cn 21 Jul 22, 2022
Dister builds and bundles your wasm web app.

dister Dister builds and bundles your wasm web app. Installation cargo install dister Requirements wasm32-unknown-unknown target: rustup target add wa

Mohammed Alyousef 1 Apr 9, 2022
a tokio-enabled data store for triple data

terminusdb-store, a tokio-enabled data store for triple data Overview This library implements a way to store triple data - data that consists of a sub

TerminusDB 307 Dec 18, 2022
A controller for mpv, requires ipc to be enabled in mpv.

Configuration Requires either the flag --input-ipc-server=/tmp/mpvsocket to be passed at mpv runtime, or for this line input-ipc-server=/tmp/mpvsocket

ValleyKnight 3 Jul 25, 2022
Emit ETW events in tracing-enabled Rust applications.

tracing-etw Emit ETW events in tracing-enabled Rust applications. This crate depends on rust_win_etw. There are four ETW events. fn NewSpan(span_id: u

Microsoft 11 Aug 10, 2022
🐙 Grams knows best. GPT3 Chat hot key enabled osx desktop app

grams Welcome to the grams repository! ?? What is grams? Grams desktop app and way to mainline into you're day to day life. grams was

drbh 5 Dec 21, 2022
Find potential unused enabled feature flags and prune them.

Potential unused, enabled feature flag finder and pruner. This cargo tool allows you to find and prune enabled, but, potentially unused feature flags

Timon 118 Jun 29, 2023
CosmWasm/Sylvia counting contract w/ IBC enabled (Cosmos, Rust, CosmWasm, Sylvia)

CosmWasm/Sylvia counting contract w/ IBC enabled (Cosmos, Rust, CosmWasm, Sylvia) This repository contains counting contract created during the study

Alex Cryp 3 Nov 13, 2023
Exploration of using Storage instead of Allocator to parameterize collections in Rust

storage-poc aims at exploring the usage of custom Storages, rather than custom Allocators. Goals This is a Proof-of-Concept aiming at: Demonstrating t

null 106 Dec 8, 2022
Custom memory allocator that helps discover reads from uninitialized memory

libdiffuzz: security-oriented alternative to Memory Sanitizer This is a drop-in replacement for OS memory allocator that can be used to detect uses of

Sergey 155 Dec 3, 2022
Arena allocator with scopes

Scoped-Arena Scoped-Arena provides arena allocator with explicit scopes. Arena allocation Arena allocators are simple and provides ludicrously fast al

Zakarum 37 Dec 6, 2022
global allocator that provides hooks for tracking allocation events

tracking-allocator A GlobalAlloc-compatible allocator implementation that provides the ability to track allocation events. examples As allocators are

Toby Lawrence 39 Dec 22, 2022
Slitter is a C- and Rust-callable slab allocator implemented primarily in Rust, with some C for performance or to avoid unstable Rust features.

Slitter is a less footgunny slab allocator Slitter is a classically structured thread-caching slab allocator that's meant to help write reliable long-

Backtrace Labs 133 Dec 5, 2022
Portable linked-list allocator designed for baremetal systems

Palloc Portable linked-list allocator for embedded / baremetal systems. Using the crate Include this in the [dependencies] section of Cargo.toml pallo

Pietro 3 Jan 11, 2022
Custom memory allocator that helps discover reads from uninitialized memory

libdiffuzz: security-oriented alternative to Memory Sanitizer This is a drop-in replacement for OS memory allocator that can be used to detect uses of

Sergey 155 Dec 3, 2022
untyped-arena provides an Arena allocator implementation that is safe and untyped with minimal complexity

untyped-arena untyped-arena provides an Arena allocator implementation that is safe and untyped with minimal complexity Usage let arena = Arena::new()

Max Bruce 1 Jan 9, 2022