고루틴의 전체 스택을 새로운 메모리 위치로 옮기면서 스택에 할당된 데이터에 대한 모든 포인터의 유효성을 유지할 수 있게 해주는 기본 기술은 무엇인가요?

질문에 대한 답변

역사

초기 Go 구현에서는 고루틴당 고정 크기 스택(1KB)을 할당했으며, 이는 높은 동시성에서 메모리를 소모하거나 깊은 재귀 중에 오버플로우되는 문제를 가지고 있었습니다. 언어는 초기 버전의 세그먼트 스택(연결된 조각)에서 Go 1.3+ 버전의 연속 스택 복사로 발전하여 캐시 로컬리티를 개선하고 포인터 관리를 단순화했습니다.

문제

고루틴이 현재 스택 세그먼트를 소모하면 runtime은 더 큰 메모리 영역을 할당하고 기존 스택 데이터를 재배치해야 합니다. 이 재배치 과정은 스택 변수를 참조하는 포인터가 유효하지 않게 되는 위험을 내포하고 있습니다. 이동 중에 메모리 주소가 변경되기 때문에 메모리 손상이나 충돌을 일으킬 수 있습니다.

해결책

컴파일러는 모든 함수 진입 지점에 스택 체크 프리엠블을 삽입하여 스택 포인터를 보호 페이지와 비교합니다. 공간이 부족할 경우 runtime.morestack을 호출하여 새 스택을 할당하고(일반적으로 크기를 두 배로 늘림) 이전 내용을 복사하며, 컴파일러가 생성한 포인터 비트맵을 사용하여 다른 스택 위치를 가리키는 모든 포인터를 찾아서 조정합니다.

코드 예제

다음 함수는 재귀 동안 스택이 증가해도 스택 변수에 대한 포인터가 여전히 유효함을 demonstrates합니다:

func Calculate(depth int, prev *int) int {
    if depth == 0 {
        return *prev
    }
    // current는 스택에 할당됨
    current := depth * 100
    
    // &current는 이전 스택 위치를 가리킬 수 있음
    // 이곳에서 스택이 증가하면, 런타임이 포인터를 업데이트함
    return Calculate(depth-1, &current) + *prev
}

실행은 새 스택에서 업데이트된 레지스터와 함께 재개되어 모든 포인터가 올바른 새 주소를 참조하도록 보장합니다.

현실 상황

상황

재귀적 주문 책 계산을 처리하는 금융 매칭 엔진은 거래량이 높은 시장 이벤트 동안 재귀 깊이가 초기 2KB 스택 할당을 초과할 때 가끔 충돌하는 문제를 겪었습니다. 시스템은 동시 연결을 처리하는 수백만 개의 경량 고루틴을 손상시키지 않고 재귀 알고리즘의 명확성을 유지하는 솔루션이 필요했습니다.

문제

매칭 알고리즘은 깊은 재귀를 사용하여 트리 형태의 주문 깊이를 탐색했으며, 거래량이 정점에 이를 때 스택 오버플로우 패닉이 발생했습니다. 솔루션은 대부분 유휴 고루틴을 위해 사전 할당된 큰 스택에 기가바이트의 메모리를 낭비하지 않고 안전하게 무한 재귀를 처리해야 했습니다.

솔루션 1: 고정 대형 스택

모든 고루틴에 대해 큰 스택을 미리 할당하기 위해 debug.SetMaxStack를 사용하거나 runtime 기본값을 수정했습니다. 장점: 성장 오버헤드와 오버플로우 위험을 완전히 제거합니다. 단점: 유휴 연결 핸들러를 위해 과도한 메모리를 소모하여 경량 고루틴의 약속을 위반하고 최대 가능 동시성을 감소시킵니다.

솔루션 2: 반복 변환

재귀 트리 탐색을 반복 알고리즘으로 다시 작성하고 탐색 상태를 추적하기 위해 명시적으로 힙에 할당된 스택 슬라이스를 사용합니다. 장점: 예측 가능한 메모리 사용량과 스택 오버플로우 위험이 없습니다. 단점: 코드 복잡성이 증가하고 알고리즘의 명확성이 상실되며, 높은 거래량 중 자주 슬라이스를 할당하는 추가 가비지 수집 압력이 발생합니다.

솔루션 3: 동적 스택 성장

재귀 설계를 유지하되 Go의 연속 스택 성장을 활용하여 컴파일러가 정확한 포인터 맵으로 함수 프레임을 최적화하도록 합니다. 장점: 깔끔한 재귀 논리를 유지하고 실제 필요에 비례하여 메모리를 사용하며, 코드 변경 없이 트래픽 급증을 자동으로 처리합니다. 단점: 스택 복사 중 마이크로초 단위의 지연이 발생하지만, 이는 작은 기본 스택과 효율적인 복사로 완화됩니다.

선택된 접근법

솔루션 3이 선택되었는데, 스택 복사의 100나노초 오버헤드가 네트워크 대기 시간에 비해 미미하고 수학적인 재귀 매칭 알고리즘의 명확성을 유지했기 때문입니다. 우리는 무한 루프가 1GB 스택을 소모하는 것을 방지하기 위해 재귀 깊이 제한을 안전 장치로 추가했습니다.

결과

시스템은 시장 스트레스 테스트 중에 50,000개의 동시 재귀 계산을 충돌 없이 지속할 수 있었습니다. 메모리 사용량은 100,000개의 고루틴에 대해 300MB 미만으로 유지되었으며, 스택 성장 이벤트 동안 p99 대기 시간이 2마이크로초 이하로 증가하여 고빈도 거래 요구 사항을 만족했습니다.

후보들이 자주 놓치는 점

왜 스택 복사가 스택이 새로운 메모리 주소로 이동할 때 스택 변수에 대한 포인터를 깨뜨리지 않나요?

runtime은 모든 함수에 대해 컴파일러가 생성한 스택 맵(비트맵)에 의존합니다. 이 맵은 스택 프레임의 어떤 슬롯에 포인터가 포함되어 있는지를 나타냅니다. runtime.copystack 중에 런타임은 이러한 맵을 반복하며, 이전 스택 범위를 가리키는 모든 포인터를 찾아 새 스택의 해당 오프셋으로 업데이트합니다. 이렇게 하면 물리적 메모리 주소가 변경된 후에도 모든 참조가 유효하게 유지되고 올바른 새 위치를 가리키게 됩니다.

Go는 CGO 호출 중 스택 데이터에 대한 포인터를 처리하는 방법은 무엇인가요?

CGO 실행은 항상 C 코드에 들어가기 전에 시스템 스택(g0)으로 전환됩니다. runtime은 C 함수에 노출된 고루틴 스택 포인터가 없도록 보장합니다. C 코드가 실행되는 동안(별도의 고루틴을 통해) 스택이 증가하더라도 C 스택은 영향을 받지 않습니다. C에서 Go로 돌아오면, 런타임은 runtime.entersyscall 전환 동안 저장된 업데이트된 스택 포인터를 사용하여 (가능성 있는 이동된) 고루틴 스택으로 다시 전환합니다.

치명적인 오류 "runtime: goroutine stack exceeds 1000000000-byte limit"의 원인은 무엇이며 일반적인 성장과 어떻게 다른가요?

일반적인 스택 확장은 더 큰 연속 영역으로 복사되는 반면, 이 오류는 runtime.morestack이 요청된 성장이 하드 리미트(64비트 시스템에서 1GB)를 초과할 것이라고 감지할 때 발생합니다. 이는 무한 재귀 또는 비정상적인 할당을 나타냅니다. 일반적인 성장 방식은 투명하고 복사 기반인데, 이 한계에 도달하면 즉각적인 패닉이 발생합니다. 왜냐하면 runtime이 시스템 OOM의 위험 없이 메모리 요청을 충족할 수 없으며, 실행을 계속하는 것이 안전하지 않기 때문입니다.