Démontrez le mécanisme architectural par lequel **Rust** exploite les motifs de bits invalides pour effectuer une optimisation des valeurs niches sur des énumérations comme **Option<NonZeroU32>**, et spécifiez les contraintes de validité qui qualifient un type en tant que porteur de niche viable.

Réponse à la question.

Rust utilise une stratégie d'optimisation de mise en page connue sous le nom de remplissage de valeur niche pour éliminer la surcharge de stockage des discriminants d’énumération lorsque les variantes contiennent des types avec des motifs de bits invalides. Le compilateur identifie des valeurs "niche" dans la plage représentable d'un type—comme la valeur zéro pour NonZeroU32 ou le pointeur nul pour les références—et réaffecte ces motifs de bits pour coder d'autres variantes d'énumérations comme None. Cette transformation repose sur le type de charge utile possédant une plage de validité restreinte définie par ses propriétés intrinsèques ou les attributs internes rustc_layout. Pour qu'un type serve de porteur de niche valide, il doit présenter au moins un motif de bits qui constitue un comportement indéfini à construire ou à lire, permettant ainsi au compilateur de réserver ce motif pour les variantes alternatives de l'énumération sans allouer d'espace supplémentaire pour le discriminant.

Situation de la vie réelle

En développant un moteur de trading haute fréquence, notre équipe a rencontré une forte pression sur le cache lors du stockage de millions de timestamps de commande dans un Vec<Option<u64>>. Chaque timestamp optionnel consommait 16 octets en raison de l’alignement et de la surcharge du discriminant, malgré le fait que les timestamps eux-mêmes étaient strictement des valeurs Unix positives. Nous avions urgemment besoin de réduire l'empreinte mémoire sans compromettre la sécurité ni recourir à des pointeurs bruts qui compliqueraient les garanties Send et Sync requises pour le traitement inter-thréorique.

Une approche envisagée était le conditionnement manuel des bits en utilisant des valeurs brutes u64 et des valeurs sentinelles zéro avec des fonctions de conversion non sécurisées. Cette solution promettait une efficacité maximale de la mémoire mais introduisait des risques catastrophiques : une erreur de logique pourrait construire un NonZeroU64 invalide ou déréférencer un pointeur nul déguisé en zéro, violant les invariants de sécurité mémoire de Rust. De plus, cela nécessiterait d'importants audits et des blocs unsafe que l'équipe cherchait à éviter.

Un autre candidat consistait à utiliser directement Optionstd::num::NonZeroU64, tirant parti de l'optimisation de niche garantie par la bibliothèque standard. Cette approche maintenait une pleine sécurité de type et des expressions match ergonomiques tout en s'assurant que Option occupait exactement 8 octets au lieu de 16. La contrainte principale était que nous devions garantir que les timestamps n'étaient jamais nuls, ce qui était vrai pour notre logique de domaine puisque tous les timestamps étaient postérieurs à 1970.

Nous avons sélectionné la deuxième solution, en refondant notre nouveau type Timestamp pour envelopper NonZeroU64 et valider les entrées à la frontière du système. Le résultat a été une réduction de 50 % de l'utilisation de la mémoire pour notre cache principal de carnet de commandes. Cette optimisation a éliminé le thrashing de cache et amélioré la latence de recherche de 30 %, le tout sans une seule ligne de code unsafe.

Ce que les candidats manquent souvent

Pourquoi Option<u32> consomme-t-il 8 octets alors que Option<NonZeroU32> n’en consomme que 4, et comment ce fonctionnement s’opère-t-il avec des types imbriqués comme Option<Option<NonZeroU32>> ?

Le type u32 admet tous les motifs de bits 2^32 comme valides, ne laissant aucun motif de bits "libre" pour que le compilateur le réaffecte comme variante None. Par conséquent, le compilateur doit ajouter un octet discriminant (padded à 4 octets pour l'alignement), ce qui donne un total de 8 octets. À l'inverse, NonZeroU32 déclare explicitement que le motif de bits 0x00000000 est invalide, créant une niche que Rust utilise pour encoder None, permettant à l’Option résultant d’occuper exactement 4 octets.

Pour les structures imbriquées, l'optimisation se prolonge efficacement : Option<Option<NonZeroU32>> reste à 4 octets car la Option externe utilise un motif de bits invalide différent (par exemple, 0x00000001) de l'espace niche disponible de NonZeroU32. Cette optimisation récursive se poursuit tant que le type porteur possède suffisamment de motifs de bits invalides pour accommoder toutes les valeurs discriminantes de l'énumération.

Comment les attributs de mise en page explicites comme #[repr(C)] ou #[repr(u8)] interagissent-ils avec l’optimisation de niche, et pourquoi cette interaction est-elle importante pour les frontières FFI ?

Lors de l'application de #[repr(C)] ou #[repr(u8)], le programmeur impose une mise en page mémoire fixe où le discriminant occupe un décalage spécifique avec une taille définie. Cette représentation explicite désactive effectivement l’optimisation de niche, garantissant la compatibilité ABI avec des structures C qui s'attendent à des étiquettes explicites tout en forçant l'énumération à consommer de l'espace supplémentaire pour le discriminant.

Dans les contextes FFI, cette distinction s'avère critique car le code C s'attend à ce que le discriminant soit à un décalage prévisible et stable. Passer un énumération Rust optimisée pour les niches dépourvue d'attributs repr explicites à travers la frontière entraîne un comportement indéfini, tandis que #[repr(C)] garantit la stabilité de la mise en page au coût nécessaire de l'efficacité mémoire.

Qu'est-ce qui empêche MaybeUninit<T> de servir de porteur de niche pour l'optimisation d'énumération même lorsque T lui-même possède des motifs de bits invalides, comme dans Option<MaybeUninit<NonZeroU32>> ?

MaybeUninit<T> est conçu architectoniquement pour contenir n'importe quel motif de bits sans provoquer de comportement indéfini, car son but est de représenter une mémoire potentiellement non initialisée. Par conséquent, le compilateur traite MaybeUninit<T> comme n'ayant aucun motif de bits invalides, ce qui signifie que sa plage de validité englobe toutes les combinaisons de bits possibles de 2^(8*sizeof(T)). Cette validité totale élimine toute nichée disponible qui pourrait être réaffectée pour l'optimisation d'énumération, quelle que soit les propriétés de T.

Ainsi, Option<MaybeUninit<NonZeroU32>> occupe 8 octets—la taille de MaybeUninit<u32> plus le rembourrage du discriminant—bien que le NonZeroU32 sous-jacent ait une validité restreinte. Ce comportement illustre que l'optimisation de niche opère strictement sur les contraintes de validité du type immédiat plutôt que sur les propriétés transitives de ses contenus potentiels.