alloca는 어떻게 스택에서 메모리를 얻는가: _chkstk 프로빙의 원리

C 프로그래머라면 한 번쯤 alloca 계열 함수를 만난다. malloc이 힙에서 메모리를 떼어 오는 것과 달리, alloca는 현재 함수의 스택 프레임을 그 자리에서 늘려 임시 버퍼를 확보한다. 함수가 반환되면 스택이 원래대로 되돌아가면서 그 공간도 자동으로 사라지므로 별도의 해제 호출이 필요 없다. 언뜻 보면 단순히 스택 포인터를 원하는 크기만큼 아래로 옮기기만 하면 될 것 같지만, 실제 구현은 그렇게 간단하지 않다. 마이크로소프트의 레이먼드 첸이 오랜 독자 셔온 밴 네스(Shawn Van Ness)의 질문에 답하면서 이 부분을 짚었다. 핵심 질문은 이것이다. _alloca가 스택을 늘릴 때 필요한 _chkstk() 프로빙을 제대로 수행하는가?

왜 스택 포인터를 그냥 옮기면 안 되는가

이 질문의 배경을 이해하려면 가드 페이지(guard page) 개념을 먼저 알아야 한다. 윈도우를 비롯한 현대 운영체제는 스레드마다 스택 영역을 예약해 두되 실제 물리 메모리는 필요할 때마다 조금씩 커밋한다. 이때 커밋된 스택 영역의 맨 끝에 특수한 접근 표시가 붙은 가드 페이지를 하나 놓는다. 프로그램이 스택을 사용하다가 이 가드 페이지를 건드리면 예외가 발생하고, 운영체제는 그 신호를 받아 스택을 한 페이지 더 확장한 뒤 다음 위치에 새 가드 페이지를 옮겨 놓는다. 즉 스택은 한 페이지씩 순차적으로 자라야만 정상적으로 성장한다.

문제는 큰 덩어리를 한 번에 할당할 때 생긴다. 예를 들어 수 킬로바이트에서 수십 킬로바이트에 이르는 공간을 확보하려고 스택 포인터를 단번에 크게 아래로 옮기면, 가드 페이지를 건드리지 않고 그 너머로 훌쩍 뛰어넘어 버릴 수 있다. 이렇게 되면 운영체제는 스택이 커져야 한다는 신호를 받지 못하고, 프로그램은 아직 커밋되지 않은 메모리에 접근하다가 회복 불가능한 오류를 맞는다. 컴파일러가 큰 지역 변수를 가진 함수를 만들 때 이 문제를 피하도록 특별한 코드를 삽입하는 이유가 여기에 있다.

_chkstk가 하는 일

그 해법이 바로 _chkstk(내부적으로는 __chkstk)라는 스택 프로빙 루틴이다. 이 함수는 필요한 만큼의 스택을 확보하기 전에, 한 페이지 간격으로 스택의 각 페이지를 차례로 건드려(probe) 나간다. 이렇게 페이지를 하나씩 밟으면서 내려가면 가드 페이지가 순서대로 발동되어 운영체제가 스택을 정상적으로 확장하게 되고, 어떤 페이지도 건너뛰지 않는다. 프로빙이 끝난 뒤에야 스택 포인터를 실제로 조정한다. 컴파일러는 함수가 큰 지역 프레임을 만들 때 이 __chkstk 호출을 자동으로 삽입해 진입 시점에 프레임 전체를 안전하게 확보한다.

첸의 답변에서 핵심은 _alloca 역시 정확히 같은 메커니즘을 따른다는 점이다. _alloca는 스택 포인터를 조정해 메모리를 떼어 내기 전에 동일한 _chkstk 함수를 호출해 스택을 프로빙한다. 다시 말해 지역 프레임을 만들 때 쓰이는 초기 스택 프로빙과 alloca가 실행 중에 수행하는 동적 할당은 서로 다른 특수 코드가 아니라 하나의 같은 __chkstk 루틴을 공유한다. 정적으로 크기가 정해지는 프레임이든 런타임에 크기가 결정되는 alloca든, 스택을 한 페이지씩 밟아 내려가 가드 페이지 규약을 지킨다는 원리는 동일하다.

실무자가 기억할 점

이 사실은 alloca를 다루는 개발자에게 몇 가지 실질적 함의를 준다. 우선 alloca가 안전 장치 없이 스택 포인터만 조작하는 위험한 저수준 트릭이 아니라, 컴파일러가 프레임을 만들 때와 동일한 검증 경로를 거친다는 점은 안심할 만하다. 다만 프로빙은 어디까지나 가드 페이지 규약을 지키기 위한 것이지 스택 고갈 자체를 막아 주지는 않는다. alloca로 지나치게 큰 값을, 특히 사용자 입력에서 유래한 크기를 검증 없이 할당하면 결국 예약된 스택을 소진해 프로그램이 죽을 수 있다. malloc과 달리 실패를 널 반환으로 우아하게 알려 주지도 않으므로, 크기 상한을 스스로 두는 방어적 습관이 필요하다.

또한 한 페이지씩 순차적으로 프로빙한다는 특성상 큰 할당일수록 그만큼의 메모리 접근 비용이 든다는 점도 염두에 둘 만하다. 성능이 극도로 중요한 경로에서 alloca를 반복 호출한다면 이 비용이 누적될 수 있다. 결국 이 이야기는 스택 할당이라는 익숙한 동작 뒤에 운영체제의 메모리 관리 규약과 컴파일러 런타임이 촘촘히 얽혀 있음을 보여 준다. 겉으로는 스택 포인터 하나를 옮기는 단순한 연산처럼 보여도, 그 아래에서는 가드 페이지를 하나도 놓치지 않으려는 프로빙이 조용히 돌아가고 있는 것이다.