Ruby의 메모리 관리 및 가비지 컬렉션
Ruby는 힙 페이지와 슬롯을 통해 객체를 관리하며, 불필요한 객체는 가비지 컬렉션(GC)을 통해 회수됩니다. 효율적인 GC를 위해 세대별 GC 방식을 채택하고 있는데, 이는 객체를 Young 세대와 Old 세대로 나누어 관리하며 주로 Young 세대만 검사하는 Minor GC를 우선적으로 수행합니다. 그러나 Minor GC는 Old 세대 객체가 Young 세대 객체를 참조하는 경우(Old-to-Young 참조)를 놓쳐 객체가 오회수될 수 있는 문제를 안고 있습니다.
Write Barrier의 역할 및 중요성
이러한 문제를 방지하기 위해 Write Barrier가 사용됩니다. Old-to-Young 참조가 발생할 때 Write Barrier는 해당 참조를 기록하여 Minor GC가 누락된 참조를 인지하도록 돕습니다. Incremental Marking과 같은 GC 기법에서도 참조 변경을 감지하는 데 Write Barrier가 필수적입니다. Ruby에는 Write Barrier로 보호되지 않는 ‘Unprotected’ 객체도 존재하지만, 이들은 항상 Young 세대에 유지되어 Old-to-Young 참조 문제가 발생하지 않습니다. 하지만 Protected 객체의 경우, Write Barrier가 누락되면 심각한 문제가 발생할 수 있으므로 완벽한 삽입이 요구됩니다.
C 확장 및 TypedData 객체에서의 Write Barrier
Ruby의 C 확장(C Extension)은 C 언어로 Ruby 기능을 확장하는 강력한 메커니즘입니다. C API를 통해 Ruby 객체(VALUE 타입)를 조작할 수 있으며, 이때 C API 내부에서 Write Barrier가 삽입되는 경우가 많습니다. 그러나 C 데이터를 Ruby 객체로 랩핑하는 ‘TypedData’ 객체를 사용할 때는 개발자가 직접 RUBY_TYPED_WB_PROTECTED 플래그를 설정하고 필요한 모든 지점에 Write Barrier를 호출해야 합니다. TypedData 객체가 오래 생존하거나, 대량으로 생성되거나, 많은 참조를 가질 경우 Write Barrier 삽입의 이점이 커집니다.
WBCheck 도구의 구현 및 분석 방식
WBCheck는 C 확장 코드에 대한 정적 분석을 통해 Write Barrier가 필요한 위치를 찾아내고 삽입합니다. 주요 접근 방식은 다음과 같습니다:
* 전처리: GCC의 -E 옵션을 사용하여 코드 내 매크로 및 디렉티브를 전개하여 분석의 복잡성을 줄입니다.
* 구문 트리 변환: Tree-sitter 라이브러리를 활용하여 전처리된 C 코드를 구문 트리로 변환합니다. 이는 코드의 구조를 정확하게 파악하는 데 용이합니다.
* 2단계 탐색:
1. 1차 탐색: 전역 변수, 구조체 정의, 함수 시그니처 등 표면적인 정보를 수집합니다.
2. 2차 탐색: 구문 트리를 깊이 탐색하여 TypedData 객체의 C 구조체 포인터와 VALUE 타입 필드의 변경이 발생하는 지점을 특정합니다. 특히 _rb_check_typeddata 호출을 통해 구조체 포인터 획득 지점을 식별하고, 대입 및 memcpy와 같은 연산을 추적합니다.
* 함수 호출 분석: 마크된 포인터가 함수 인자로 전달될 경우, 해당 함수 내부까지 재귀적으로 탐색하여 참조 변경을 감지하며, 컨텍스트 스택을 활용하여 중첩된 호출을 처리합니다.
* Write Barrier 삽입: 참조 변경이 감지된 필드에 대해 RB_OBJ_WRITE 함수 호출을 삽입합니다.
테스트 및 향후 개선
Date, JSON, StringIO 라이브러리 테스트 결과, 대부분의 Write Barrier 필요 지점을 감지했으나, 일부 불필요한(생략 가능한) Write Barrier 체크를 줄이는 것과 strcpy 등 다양한 외부 함수 호출에 대한 대응력 강화가 향후 개선 과제로 남아 있습니다. 또한 배열이나 구조체 필드로 구조체 포인터를 받는 경우에 대한 대응도 필요합니다.