Antwort

In Rust ist der Allokator verantwortlich für die Zuweisung und Freigabe von dynamischem Speicher (Heap). Standardmäßig verwendet Rust den systemeigenen Allokator, aber die Sprache bietet die Möglichkeit, benutzerdefinierte Allokatoren über globale und lokale Schnittstellen zu verwenden. Dies kann notwendig sein für:

• Leistungsoptimierung für spezifische Aufgaben (z. B. Reduzierung der Speicherfragmentierung).
• Kontrolle des Verhaltens bei der Speicherzuweisung (z. B. Logging, Limitierung, Profiling).
• Arbeiten unter bestimmten Betriebssystemen oder auf Embedded-Geräten, wo der standardmäßige Allokator nicht verfügbar ist.

Seit 1.28 wird der globale Allokator über das Attribut #[global_allocator] definiert:

use std::alloc::System;

#[global_allocator]
static GLOBAL: System = System;

Man kann einen eigenen Allokator erstellen, indem man Traits aus std::alloc implementiert:

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

struct MyAlloc;
unsafe impl GlobalAlloc for MyAlloc {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        // Hier Logik zur Zuweisung
        std::alloc::System.alloc(layout) // delegieren
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        // Logik zur Freigabe
        std::alloc::System.dealloc(ptr, layout)
    }
}

#[global_allocator]
static GLOBAL: MyAlloc = MyAlloc;

Fangfrage

Frage: Kann man den globalen Allokator zur Laufzeit ändern, z. B. je nach Bedingungen oder Konfiguration?

Antwort: Nein! Der globale Allokator wird zur Kompilierzeit ausgewählt und statisch über #[global_allocator] festgelegt. Er kann zur Laufzeit nicht geändert oder dynamisch ausgewählt werden, da dieses Attribut den generierten Code bei der Kompilierung beeinflusst.

---

Geschichte

Ein Unternehmen hat einen Highload-Service von Linux auf eine Embedded-Plattform mit RTOS portiert. Aufgrund des Unwissens, dass der standardmäßige globale Allokator auf dieser Plattform nicht funktioniert, fiel die Anwendung mit einem Segfault bei jedem Box::new. Die Implementierung eines eigenen Allokators mit Zugriff auf statische Speicherpools half.

Geschichte

In einem Projekt zur Analyse großer Graphen wurde ein benutzerdefinierter Allokator zur Profilierung implementiert, aber es wurde vergessen, die Freigabe des Speichers richtig umzuleiten. Infolgedessen kam es zu einem Speicherleck und einer Verschlechterung der Leistung bei Lasttests.

Geschichte

Bei der Entwicklung einer Desktop-Anwendung wurde ein Drittanbieter-Allokator jemalloc verwendet, ohne die Unterschiede in der ABI zwischen den rustc-Versionen zu berücksichtigen. Dies führte zu schwer fassbaren Fehlern bei der Serialisierung von Daten, da verschiedene Teile des Codes unterschiedliche Vereinbarungen zur Speicherzuweisung erwarteten.