Jemalloc 5.4.0 apporte 160 commits après le retour de Meta

Jemalloc 5.4.0 est sorti le 17 septembre 2026, avec plus de 160 commits signés par 13 développeurs. Les notes de version parlent d'une version de nettoyage, et c'est bien la nouvelle. Jemalloc a passé des années presque immobile. Meta a déclaré plus tôt cette année qu'il investirait de nouveau dans le projet.

Un allocateur mémoire est le code qui distribue la mémoire quand un programme en demande. Chaque appel à malloc en C, et chaque allocation sur le tas dans un langage bâti dessus, passe par l'un d'eux. Jemalloc est l'alternative vers laquelle se tournent les serveurs quand l'allocateur par défaut fragmente la mémoire ou ralentit avec de nombreux fils d'exécution. Phoronix note qu'il reste populaire pour les charges serveur et le calcul haute performance, avec quelques usages sur le bureau.

Ce qui change dans 5.4.0

Changement	Effet
Plus de 160 commits de nettoyage	Refactorisation, corrections, couverture de tests élargie, options de build rangées
Nouvelle couche d'abstraction système	Regroupe le code spécifique à chaque plateforme derrière une interface
Façade modularisée	Découpe les points d'entrée en morceaux plus petits et séparables
Sélection d'arène par CPU	Un fil peut de nouveau choisir son arène selon le CPU, via thread.arena
EXTENT_ALLOC_FLAG_PINNED	Marque une projection mémoire comme non restituable dans les hooks d'extent
Corrections des avertissements GCC 16	Compile proprement avec le compilateur le plus récent

La couche d'abstraction est le plus grand changement de structure. Elle rassemble les parties qui diffèrent selon le système d'exploitation. Cette liste couvre les entrées et sorties fichier et processus, le temps, la synchronisation, la gestion du CPU, la mémoire virtuelle, la gestion de fork, la gestion des erreurs, le profilage, la cession de fil et l'accès à la configuration. Tout cela tient désormais derrière une interface, au lieu d'être dispersé dans le code.

Une arène est l'unité de séparation de jemalloc. Chacune détient ses propres réserves de mémoire, si bien que des fils utilisant des arènes différentes se gênent moins. La sélection par CPU signifie qu'un fil peut se lier à l'arène correspondant au cœur sur lequel il s'exécute. La mémoire reste ainsi près du cœur qui l'utilise.

Les hooks d'extent sont l'autre réglage avancé. Ils permettent de fournir à jemalloc votre propre mémoire, par exemple issue d'une projection partagée ou d'un périphérique. Le nouveau drapeau pinned indique à jemalloc qu'une telle projection ne doit jamais être rendue au système.

Pourquoi une version de nettoyage est la nouvelle

Les notes de version indiquent que le travail s'est concentré sur "le nettoyage de la dette technique, incluant refactorisations, corrections de bogues, amélioration de la couverture de tests et rangement des options". Ce n'est pas une liste de fonctionnalités, et c'est justement l'essentiel. Le réinvestissement de Meta, signalé par Phoronix, arrive sous forme de maintenance plutôt que d'une salve de nouvelles options.

Cet ordre compte pour qui hésite à dépendre de nouveau du projet. Redis, des programmes Rust qui l'activent, et beaucoup de serveurs de bases de données et de stockage embarquent jemalloc depuis des années. Un projet qui n'accepte que des fonctionnalités accumule exactement les cas particuliers propres à chaque plateforme qui rendent le portage suivant pénible.

Ce que cela signifie pour les développeurs

Si vous liez déjà jemalloc, la 5.4.0 est une mise à jour sans drame à tester. Éprouvez-la sur votre propre charge plutôt que sur une suite de tests de performance, car le comportement d'un allocateur dépend des tailles d'allocation et du nombre de fils que seule votre application connaît. Surveillez la mémoire résidente et la latence de queue, pas seulement le débit.

Si vous maintenez un portage vers une plateforme moins courante, lisez d'abord la couche d'abstraction système. Le code spécifique qui vivait dans des blocs #ifdef éparpillés a maintenant un seul endroit. Un correctif hors arbre devrait en devenir plus petit et plus simple à porter.

L'option d'arène par CPU mérite une mesure sur les machines à nombreux cœurs. Elle aide surtout quand beaucoup de fils allouent en même temps et que les verrous de l'allocateur deviennent le goulet. Mesurez plutôt que de supposer un gain, et comparez avec votre nombre d'arènes actuel.

Enfin, voyez les corrections d'avertissements GCC 16 comme un signal pour votre propre compilation. Les distributions passent à ce compilateur, et une dépendance qui avertit bruyamment cassera plus tard une compilation stricte.