질문에 대한 답변

역사: Rust의 메모리 관리 시스템은 단일 글로벌 할당자 인터페이스(GlobalAlloc, Rust 1.28에서 안정화됨)에서 더 유연하고 유형 인식 시스템(Allocator, 현재 불안정하지만 std::alloc에서 사용 가능)으로 발전했습니다. GlobalAlloc은 운영 체제의 메모리 원시 요소(예: malloc, VirtualAlloc)에 대한 저수준 브리지를 제공하며, 유형 정보 없이 원시 포인터와 바이트 크기만을 다룹니다.

문제는 GlobalAlloc이 컴파일러가 검증할 수 없는 원시 메모리 조작을 노출하기 때문에 발생합니다. 구현자는 정렬 보장, 할당/해제 페어링, 이중 해제 금지를 포함한 중요한 불변 조건을 수동으로 시행해야 합니다. GlobalAlloc이 Box, Vec, Rc를 기반으로 하므로, 위반이 발생할 경우 전체 프로그램에 걸쳐 정의되지 않은 동작이 전파되어, 이러한 안전 계약에 대한 책임을 프로그래머가 져야 함을 알리는 unsafe impl 마커가 필요합니다.

해결책은 Layout 계약에 엄격하게 준수하는 것입니다. alloc 메서드는 **Layout::align()**을 만족하는 포인터를 반환해야 하며, dealloc은 할당에 사용된 동일한 레이아웃과 함께 호출되어야 합니다. 또한 할당자는 안전한 추상화에 의해 참조되는 동안 메모리가 회수되지 않도록 해야 합니다. Allocator 특성은 내부적으로 Layout 계산을 처리하여 이러한 위험을 완화하고, 원시 작업은 기본 GlobalAlloc 구현에 위임합니다.

use std::alloc::{GlobalAlloc, Layout, System};
use std::sync::atomic::{AtomicUsize, Ordering};

struct CountingAllocator {
    bytes_allocated: AtomicUsize,
}

unsafe impl GlobalAlloc for CountingAllocator {
    unsafe fn alloc(&self, layout: Layout) -> *mut u8 {
        let ptr = System.alloc(layout);
        if !ptr.is_null() {
            self.bytes_allocated.fetch_add(layout.size(), Ordering::SeqCst);
        }
        ptr
    }
    
    unsafe fn dealloc(&self, ptr: *mut u8, layout: Layout) {
        System.dealloc(ptr, layout);
        self.bytes_allocated.fetch_sub(layout.size(), Ordering::SeqCst);
    }
}

#[global_allocator]
static GLOBAL: CountingAllocator = CountingAllocator {
    bytes_allocated: AtomicUsize::new(0),
};

실생활 상황

고주파 거래 엔진을 개발하는 팀은 표준 라이브러리의 할당자가 글로벌 힙의 잠금 경합으로 인해 허용할 수 없는 지연 변동을 유발한다는 것을 관찰했습니다. 그들은 핫 경로 주문서 업데이트를 보장하기 위해 큰 페이지에서 미리 할당된 사용자 정의 범프 할당기가 필요했습니다.

여러 솔루션이 평가되었습니다. 첫 번째 접근은 시스템 할당자를 뮤텍스 보호 풀로 감싸는 것이었지만, 이는 단지 경합을 이동시키고 지연 요구 사항을 위반했습니다. 두 번째 접근은 불안정한 Allocator API를 사용하는 것이었으며, 특정 주문 구조를 위한 유형화된 아레나를 생성하는 것이었지만, 이를 위해 Vec 및 Box 사용에 대한 광범위한 리팩토링이 필요했으며, 프로덕션 배포에 대한 안정성 문제에 직면했습니다.

궁극적으로 선택된 세 번째 솔루션은 거래 스레드 내에서 모든 동적 할당을 가로채기 위해 GlobalAlloc을 구현하고, 이를 통해 mmap 영역 뒤에 있는 스레드 로컬 범프 할당기로 라우팅하는 것이었습니다. 이 구현은 범프 할당기가 원시 포인터를 관리하고 반환된 포인터가 최대 64바이트 캐시 라인 경계에 대한 정렬을 유지해야 하므로 unsafe impl을 요구했습니다. 팀은 기존 컬렉션 유형을 수정하지 않고 시스템 전반에 개입할 수 있는 이 경로를 선택했지만, Miri로 테스트하여 dealloc에 전달된 Layout이 항상 원래 할당과 일치하는지 확인해야 했습니다. 그 결과 p99 지연이 40% 감소했지만, 팀은 특별한 시장 변동성 동안 메모리 누수를 방지하기 위해 unsafe 코드 블록에 대한 엄격한 감사 프로토콜을 유지했습니다.

지원자가 자주 놓치는 점

왜 dealloc에 전달되는 Layout이 alloc에 주어진 것과 정확히 일치해야 하며, 크기가 다르지만 정렬이 올바른 경우 어떤 일이 발생합니까?

GlobalAlloc 계약은 할당과 해제에 사용된 Layout 사이의 비트 단위 일치를 요구합니다. 많은 할당자(예: jemalloc 또는 dlmalloc)가 할당된 블록 내에 메타데이터를 삽입하거나 크기 클래스 분리 목록을 유지하기 때문입니다. 다른 크기를 전달하면(심지어 더 작은 경우에도) 할당자가 잘못된 빈에서 찾거나 결합을 위한 잘못된 오프셋을 계산하게 되어 힙 손상이나 이중 해제 취약점이 발생할 수 있습니다. 이는 일반적으로 포인터만 요구하는 C의 free와 다르며, Rust의 요구 사항이 더 엄격하지만 할당자 독립성을 보장하기 위해 필요합니다.

박스를 드롭할 때 GlobalAlloc은 Box::new와 어떻게 상호 작용하며, 할당자 자체의 Drop을 구현하는 것이 왜 문제가 됩니까?

Box::new가 호출되면, 이는 #[global_allocator] 정적을 통해 GlobalAlloc::alloc를 호출합니다. Box를 드롭할 때 컴파일러는 자동으로 유형의 Layout과 함께 GlobalAlloc::dealloc을 호출합니다. 지원자들은 종종 GlobalAlloc 구현 자체가 'static이고 스레드 안전( Sync 구현)해야 하며, 할당된 메모리를 참조하는 상태를 유지해서는 안 된다는 점을 놓치는 경우가 많습니다. 이는 할당자를 드롭하는 과정에서 순환 의존성을 발생시키며, 프로그램 종료 중 사용 후 해제를 초래할 수 있습니다.

왜 GlobalAlloc::alloc_zeroed의 안전 요구 사항이 alloc과 다르며, 구현이 단순히 alloc 다음에 std::ptr::write_bytes를 호출할 수 없는 이유는 무엇입니까?

alloc_zeroed는 이론적으로 alloc과 제로화로 구현할 수 있지만, 표준 라이브러리는 할당자가 OS 특정 제로 페이지 최적화(예: Linux의 MAP_ANONYMOUS가 사전 제로화된 페이지를 반환)를 활용할 수 있도록 별도의 메서드로 제공합니다. 안전성 관점에서 alloc_zeroed는 반환된 메모리가 제로 바이트를 포함해야 한다는 보장을 해야 하며, 이는 alloc보다 더 강력한 후 조건입니다( alloc은 초기화되지 않은 메모리를 반환합니다). 구현이 잘못된 제로화 주장을 하고 쓰레기 값을 반환하면, 안전한 코드가 제로 초기화를 가정하고(보안 민감한 맥락에서 중요) 초기화되지 않은 데이터를 읽게 되어 Rust의 안전 보장을 위반할 수 있습니다.