질문에 대한 답변.
Rust는 열거형 변수가 잘못된 비트 패턴을 포함하는 타입일 때 열거형 식별자의 저장 오버헤드를 제거하기 위해 틈새 값 채우기라는 레이아웃 최적화 전략을 채택합니다. 컴파일러는 NonZeroU32의 0 값이나 참조의 널 포인터와 같이 타입의 표현 가능한 범위 내에 있는 "틈새" 값을 식별하고, 이러한 비트 패턴을 다른 열거형 변수를 인코딩하는 데 재사용하는 방식입니다. 이 변환은 페이로드 타입이 내재적 속성 또는 내부 rustc_layout 속성에 의해 정의된 제한된 유효성 범위를 가지는 데 의존합니다. 타입이 유효한 틈새 운반자로 작용하기 위해서는, 컴파일러가 해당 패턴을 추가로 할당하지 않고도 다른 열거형 변수를 위해 예약할 수 있도록 정의되지 않은 동작을 구성하거나 읽는 비트 패턴을 최소한 하나 이상 제공해야 합니다.
일상적인 상황
고주파 거래 엔진을 개발하면서, 우리 팀은 **Vec<Option<u64>>**에 수백만 개의 주문 타임스탬프를 저장할 때 심각한 캐시 압박을 경험했습니다. 각 선택적 타임스탬프는 정렬 및 식별자 오버헤드 때문에 16바이트를 소비했으며, 타임스탬프 자체는 엄격히 양수인 유닉스 에폭 값이었습니다. 우리는 안전성을 희생하거나 Send 및 Sync 보장을 복잡하게 할 수 있는 원시 포인터에 의존하지 않고 메모리 사용량을 줄여야 했습니다.
고민했던 한 가지 접근 방식은 원시 u64 값과 널 값을 사용하여 수동 비트 패킹을 하는 것이었습니다. 이 솔루션은 최대한의 메모리 효율성을 약속했지만, 치명적인 위험을 초래했습니다: 논리 오류가 유효하지 않은 NonZeroU64를 구성하거나 0으로 위장한 널 포인터를 역참조할 수 있게 되어 Rust의 메모리 안전 불변성을 위반했기 때문입니다. 더욱이, 팀이 피하고자 했던 광범위한 감사 추적 및 unsafe 블록을 필요로 했습니다.
또 다른 후보는 표준 라이브러리의 보장된 틈새 최적화를 활용하여 **Optionstd::num::NonZeroU64**를 직접 사용하는 것이었습니다. 이 접근 방식은 Match 표현식을 통한 완전한 타입 안전성과 인체공학을 유지하면서 Option이 16바이트 대신 정확히 8바이트를 차지하도록 보장했습니다. 주요 제약 사항은 타임스탬프가 절대 0이 아닐 것이라는 점을 보장해야 했으며, 이는 모든 타임스탬프가 1970년 이후이기 때문에 도메인 논리상 진실로 확보되었습니다.
우리는 두 번째 솔루션을 선택하여 Timestamp newtype을 NonZeroU64로 감싸고 시스템 경계에서 입력을 검증했습니다. 그 결과, 주요 주문서 캐시의 메모리 사용량이 50% 감소했습니다. 이 최적화는 캐시 쓰레기를 제거하고 조회 지연 시간을 30% 개선했으며, 모든 과정에서 단 한 줄의 unsafe 코드도 없이 이루어졌습니다.
후보자들이 종종 놓치는 점
Option<u32>가 8바이트를 소모하는 반면 Option<NonZeroU32>는 왜 4바이트만 소모하며, 이 최적화가 Option<Option<NonZeroU32>>와 같은 중첩 타입에서 어떻게 작용하는가?
u32 타입은 모든 2^32 비트 패턴을 유효하다고 인정하므로, 컴파일러가 None 변수를 위해 재사용할 수 있는 "여유" 비트 패턴이 없습니다. 따라서 컴파일러는 정렬을 위해 4바이트로 패딩된 식별자 바이트를 추가해야 하며, 결과적으로 총 8바이트가 소모됩니다. 반대로, NonZeroU32는 비트 패턴 0x00000000이 유효하지 않다고 명시적으로 선언하여 Rust가 None을 인코딩하는 데 사용하는 틈새를 만들어, 결과로서 Option이 정확히 4바이트를 차지하도록 합니다.
중첩 구조의 경우, 최적화 사슬은 효과적으로 이어집니다: Option<Option<NonZeroU32>>는 외부 Option이 NonZeroU32의 사용 가능한 틈새 공간과 다른 유효하지 않은 비트 패턴(예: 0x00000001)을 이용하기 때문에 여전히 4바이트를 유지합니다. 이 재귀적 최적화는 운반 타입이 모든 열거형 식별자 값을 수용할 수 있도록 충분한 유효하지 않은 비트 패턴을 소유할 경우 지속됩니다.
#[repr(C)] 또는 #[repr(u8)]와 같은 명시적 레이아웃 속성이 틈새 최적화와 어떻게 상호 작용하며, 이 상호 작용이 FFI 경계에 왜 중요한가?
#[repr(C)] 또는 **#[repr(u8)]**를 적용할 때, 프로그래머는 식별자가 특정 오프셋에 정의된 크기로 존재하도록 하는 고정 메모리 레이아웃을 의무화합니다. 이 명시적 표현은 틈새 최적화를 효과적으로 비활성화하여, 식별자가 명시적인 태그를 기대하는 C 구조체와의 ABI 호환성을 보장하지만, 열거형이 정체성을 위해 추가 공간을 소모하도록 강제합니다.
FFI 문맥에서 이 구별은 중요합니다. 왜냐하면 C 코드가 식별자가 예측 가능하고 안정적인 오프셋에서 존재할 것으로 예상하기 때문입니다. 틈새 최적화된 Rust 열거형을 명시적 repr 속성 없이 경계를 넘기는 것은 정의되지 않은 동작을 초래하며, 반면에 **#[repr(C)]**는 메모리 효율성을 포기하는 대신 레이아웃의 안정성을 보장합니다.
MaybeUninit<T>가 비록 T 자체에 잘못된 비트 패턴이 있어도 열거형 최적화를 위한 틈새 운반자로 작용하지 못하는 이유는 무엇인가?
**MaybeUninit<T>**는 정의되지 않은 동작을 유발하지 않으면서 모든 비트 패턴을 보유할 수 있도록 설계되었습니다. 그 목적은 잠재적으로 초기화되지 않은 메모리를 나타내는 것입니다. 결과적으로 컴파일러는 **MaybeUninit<T>**를 유효하지 않은 비트 패턴이 없는 것으로 간주하며, 따라서 유효성 범위는 2^(8*sizeof(T)) 가능한 모든 비트 조합을 포함합니다. 이 전체 유효성은 열거형 최적화를 위해 재사용할 수 있는 틈새를 모두 제거합니다. 따라서 Option<MaybeUninit<NonZeroU32>>는 **MaybeUninit<u32>**의 크기와 식별자 패딩을 포함하여 8바이트를 차지하며, 이 동작은 틈새 최적화가 타입의 유효성 제약에만 엄격하게 작용하는 것을 보여줍니다.