Rust использует оптимизацию нишевых значений (также называемую заполнением ниш) для устранения хранения дискриминанта для перечислений, когда вариант содержит тип с недопустимыми битовыми паттернами. Для Option<&T> вариант None представлен значением нулевого указателя — битовым паттерном, которое недопустимо для &T, так как ссылки всегда должны быть ненулевыми. Это позволяет компилятору хранить дискриминант неявно внутри самого указателя, гарантируя, что Option<&T> занимает ровно одно машинное слово. Эта оптимизация применяется к любому типу, обладающему нишевыми значениями — недопустимым битовым паттернам, таким как 0 для NonZeroU32, значениям вне 0 или 1 для bool, или специфическим сигнальным значениям в #[repr(C)] структурах.
При разработке высокопроизводительного абстрактного синтаксического дерева (AST) для компилятора, обрабатывающего миллионы узлов, мы столкнулись с серьезным давлением на память из-за указателей на родительские и дочерние узлы. Каждый узел требовал опциональных ссылок на своего родителя, левого ребенка и правого ребенка, изначально реализованных как Option<Box<Node>>.
Использование Option<Box<Node>> привело к нагрузке в 16 байт на указатель на 64-битных системах — 8 байт для указателя Box и 8 байт для дискриминанта и выравнивания. Для дерева с 10 миллионами узлов это составило 480 мегабайт только для указателей на связи, что превышало наш бюджет памяти.
Мы рассмотрели три подхода. Первый — заменить Option<Box<Node>> на сырые указатели (*mut Node), используя нуль для None. Это устранило накладные расходы, но потребовало бы unsafe блоков по всему коду, что рисковало образовать висячие указатели и нарушить гарантии безопасности Rust. Второй подход — использование аллокатора арены с индексами (usize) вместо указателей. Хотя этот подход удобен для кеша, Option<usize> по-прежнему требовал 16 байт из-за отсутствия ниш в usize, а арифметика индексов усложняла API.
Мы выбрали третий подход: Option<NonNull<Node>>, обернутый в безопасную абстракцию ParentPtr. NonNull<T> имеет нишу по адресу 0, что позволяет Option<NonNull<Node>> оставаться 8 байт. Мы инкапсулировали unsafe разыменование внутри методов-оберток, сохраняя безопасность памяти, добиваясь при этом абстракции без дополнительных затрат. Это сократило объем памяти AST на 50%, уложившись в наш лимит в 256 МБ, не жертвуя безопасностью.
Почему Option<Option<bool>> остается одним байтом, в то время как Option<Option<usize>> расширяется до 16 байт?
bool имеет 254 нишевых значения, так как только битовые паттерны 0 и 1 являются допустимыми. Первый уровень Option использует одну нишу (например, 2) для представления None, оставляя 253 оставшиеся ниши. Второй уровень Option использует еще одну нишу (например, 3) для своего варианта None. Таким образом, Option<Option<bool>> все еще помещается в один байт. Напротив, usize не имеет недопустимых битовых паттернов — все 2^64 значения являются допустимыми адресами памяти или данными. Поскольку ниш нет, Option<usize> должен добавить байт дискриминанта, что приводит к 16 байтам (8 для данных, 8 для выравнивания). Вложенные уровни Option не могут оптимизироваться дальше без доступных ниш, поэтому Option<Option<usize>> остается 16 байт с внутренней логикой дискриминанта.
Почему компилятор отвергает оптимизацию ниш для перечислений, помеченных как #[repr(C)], даже если тип полезной нагрузки содержит ниши?
Атрибут #[repr(C)] гарантирует совместимый с C макет памяти с стабильным порядком полей и явным хранением дискриминанта на предсказуемом смещении. Стандарт языка C не поддерживает перекрывающиеся значения дискриминанта с полезными данными — дискриминанты должны находиться в специальных местах памяти для обеспечения совместимости FFI. Хотя такая структура, как NonNull<T>, содержит ниши (нулевой указатель), перечисления #[repr(C)] не могут использовать их для перекрытия с дискриминантом, потому что внешний код на C ожидает считать отдельное значение дискриминанта по фиксированному смещению. Это ограничение сохраняет совместимость за счет эффективности использования памяти, обеспечивая, что sizeof(Option<&T>) равно sizeof(&T) + sizeof(discriminant) под #[repr(C)], обычно составляет 16 байт, а не 8.
Как работает функция std::mem::discriminant для типов, таких как Option<&T>, у которых отсутствует явное хранение дискриминанта в памяти?
std::mem::discriminant возвращает непрозрачное значение Discriminant<T>, которое уникально идентифицирует вариант перечисления независимо от представления памяти. Для Option<&T> компилятор генерирует код, который выводит дискриминант, проверяя значение указателя — возвращая константу, представляющую Some, если указатель ненулевой, и константу, представляющую None, если он нулевой. Хотя отдельное место памяти не хранит тег дискриминанта, тип Discriminant абстрагирует это вычисление, позволяя сравнивать варианты через == без раскрытия деталей кодирования ниш. Это демонстрирует, что дискриминант работает на основе семантической идентичности варианта, а не физической компоновки памяти, обеспечивая согласованное поведение в оптимизированных и неоптимизированных представлениях перечислений.