Answer

In Rust, an allocator is responsible for allocating and freeing dynamic memory (heap). By default, Rust uses the standard system allocator, but the language provides the ability to use custom allocators through global and local interfaces. This may be needed for:

• Performance optimization for specific tasks (for example, reducing memory fragmentation).
• Controlling behavior during memory allocation (for example, logging, limiting, profiling).
• Working under specific operating systems or on embedded devices, where the standard allocator is not available.

Since version 1.28, the global allocator is set using the #[global_allocator] attribute:

use std::alloc::System;

#[global_allocator]
static GLOBAL: System = System;

You can create your own allocator by implementing traits from std::alloc:

use std::alloc::{GlobalAlloc, Layout};

struct MyAlloc;
unsafe impl GlobalAlloc for MyAlloc {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        // Allocation logic here
        std::alloc::System.alloc(layout) // delegate
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        // Freeing logic
        std::alloc::System.dealloc(ptr, layout)
    }
}

#[global_allocator]
static GLOBAL: MyAlloc = MyAlloc;

Trick question

Question: Can the global allocator be changed at runtime, for example, depending on conditions or configuration?

Answer: No! The global allocator is chosen at compile time and is set statically using #[global_allocator]. It cannot be changed at runtime or selected dynamically, as this attribute affects the generated code during compilation.

---

Story

A company ported a high-load service from Linux to an embedded platform with RTOS. Due to unawareness that the standard global allocator does not work on this platform, the application crashed with a segfault on any Box::new. The implementation of a custom allocator with access to static memory pools helped.

Story

In a project analyzing large graphs, a custom allocator was implemented for profiling, but the correct memory freeing redirection was forgotten. As a result, a memory leak occurred and performance degraded during load tests.

Story

When developing a desktop application, a third-party allocator jemalloc was applied, without considering ABI differences between rustc versions. This led to elusive crashes during data serialization, as different parts of the code expected different memory allocation agreements.