Réponse

En Rust, l'allocateur est responsable de l'allocation et de la libération de la mémoire dynamique (heap). Par défaut, Rust utilise l'allocateur système standard, mais le langage permet d'utiliser des allocateurs personnalisés via des interfaces globales et locales. Cela peut être nécessaire pour :

• Optimiser les performances pour des tâches spécifiques (par exemple, réduire la fragmentation de la mémoire).
• Contrôler le comportement lors de l'allocation de mémoire (par exemple, journalisation, limitation, profilage).
• Travailler sous des systèmes d'exploitation spécifiques ou sur des dispositifs embarqués, où l'allocateur standard n'est pas disponible.

Depuis la version 1.28, l'allocateur global est défini à l'aide de l'attribut #[global_allocator] :

use std::alloc::System;

#[global_allocator]
static GLOBAL: System = System;

Il est possible de créer son propre allocateur en implémentant les traits de std::alloc :

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

struct MyAlloc;
unsafe impl GlobalAlloc for MyAlloc {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        // Logique d'allocation
        std::alloc::System.alloc(layout) // délégation
    }
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        // Logique de libération
        std::alloc::System.dealloc(ptr, layout)
    }
}

#[global_allocator]
static GLOBAL: MyAlloc = MyAlloc;

Question piège

Question : Peut-on changer l'allocateur global au runtime, par exemple, en fonction de conditions ou de configurations ?

Réponse : Non ! L'allocateur global est choisi au moment de la compilation et défini statiquement via #[global_allocator]. Il n'est pas possible de le changer au runtime ou de le choisir dynamiquement, car cet attribut influence le code généré lors de la compilation.

---

Histoire

Une entreprise a porté un service highload sous Linux sur une plateforme embarquée avec RTOS. Faute de savoir que l'allocateur global standard ne fonctionnait pas sur cette plateforme, l'application plantait avec un segfault lors de chaque Box::new. La mise en œuvre d'un allocateur personnalisé avec accès à des pools de mémoire statiques a aidé.

Histoire

Dans un projet d'analyse de grands graphes, un allocateur personnalisé a été intégré pour le profilage, mais on a oublié de rediriger correctement la libération de la mémoire. En conséquence, une fuite de mémoire (leak) s'est produite et la performance a diminué lors des tests de charge.

Histoire

Lors du développement d'une application de bureau, un allocateur tiers jemalloc a été utilisé, sans tenir compte de la différence d'ABI entre les versions de rustc. Cela a entraîné des plantages difficiles à détecter lors de la sérialisation des données, car différentes parties du code attendaient des conventions d'allocation de mémoire différentes.