jemalloc 사후 회고문

• jemalloc는 2004년에 시작되어 약 20년 동안 널리 사용된 메모리 할당기임
• FreeBSD와 Mozilla Firefox, Facebook 인프라에서 중요한 역할을 하였으나, 최근 Meta의 내부 변화로 인해 공식적 개발이 중단됨
• 저장 공간 단편화 문제와 확장성 문제 등 다양한 도전을 거치면서, 성능 향상 및 통계 수집, 테스트 인프라 등 다양한 기능이 추가됨
• Valgrind 지원 제거와 외부 조직과의 협력 부재 등으로 외부 사용자와의 소통 부족 문제 발생함
• 앞으로 포크(fork) 를 통한 새로운 발전 가능성은 열려 있으나, 공식적인 메인 개발은 더 이상 진행되지 않을 전망임

개요

• jemalloc은 2004년 처음 고안된 오픈 소스 메모리 할당기로, 성능과 확장성 개선을 목표로 개발되어 20년간 주요 오픈 소스 프로젝트 및 빅테크 인프라에서 활발히 활용됨
• 최근 메인 개발이 중단되어, 앞으로는 포크나 개별 조직 차원의 유지 관리가 예상됨

Phase 0: Lyken

• 2004년 Lyken이라는 과학 컴퓨팅용 프로그래밍 언어 개발 과정에서 수동 메모리 할당기부터 시작함
• Lyken 내부의 할당기는 2005년 5월 기능상 완성됨
• 할당기는 이후 FreeBSD에 통합되면서, Lyken에서는 시스템 할당기의 얇은 래퍼만 남기고 제거됨
• 제거 이유는 FreeBSD 통합 후, 시스템 할당기 부족한 부분(스레드별 할당량 추적)만 명확해졌기 때문임
• 재미있게도, 나중에 jemalloc에 Lyken 시절에 필요로 했던 통계 수집 기능이 추가됨

Phase 1: FreeBSD

• 2005년 멀티프로세서 컴퓨터가 보편화되던 시기 FreeBSD는 phkmalloc을 사용 중이었지만, 병렬 스레드 환경에 적합하지 않았음
• Lyken 할당기가 확장성 개선에 명확한 이점이 있어, 이를 FreeBSD에 통합하면서 곧 jemalloc이라는 이름이 붙음
• 그러나 KDE 애플리케이션 등에서 심각한 단편화 문제가 발생하여 생존 가능성이 의심받음
• 단편화 원인은 크기 구분 없는 통합 공간 할당 방식 때문이었으며, 연구 끝에 크기별 구역 분리 알고리듬으로 구조를 대폭 변경함
• 이 과정 내용은 2006년 BSDCan 논문에 기록됨

Phase 1.5: Firefox

• 2007년 Mozilla Firefox 3 출시를 앞두고 Windows 환경에서 메모리 단편화가 큰 이슈였음
• jemalloc을 Linux에 포팅하는 일은 쉬웠으나 Windows는 까다로웠음
• FreeBSD libc에 저장된 jemalloc을 Mozilla에서 포크하여 이식성과 호환성 개선을 진행함
• 시간이 흐르며 Mozilla가 jemalloc 업스트림에 많은 개선을 기여했으나, 항상 포크 버전이 더 높은 성능을 보임
• 이는 성능 회귀 문제 때문인지, 특정 환경에 맞춘 최적화 때문인지는 불명확함

Phase 2: Facebook

• 2009년 Facebook 입사 시, jemalloc의 최대 장애 요인은 도구 미비(프로파일링, 리크 탐지)의 문제였음
• 이를 보완하여 pprof 호환 힙 프로파일링 기능을 jemalloc 1.0.0에서 도입함
• 개발은 Github로 이관 후, 사용자 및 외부 기여자와 함께 테스트 인프라, Valgrind 지원, JSON 통계, 새로운 페이지 관리 등 많은 개선이 이루어짐
• 내부적으로는 Facebook의 거대한 텔레메트리 시스템 덕분에 성능 최적화와 회귀 방지에 큰 도움이 됨
• 5.0.0 버전에서 Valgrind 지원 제거는 내부에서 사용하지 않아 결정했으나, Rust 개발자 등 외부에서 반발이 강했음
• 이후 Facebook/Meta의 조직 변화로 jemalloc 팀이 축소되고, 핵심 기술 투자보다 효율성 중심의 사업 전략으로 전환됨
• 이에 따라 Huge Page Allocation과 같은 대형 기능의 개발이 정체, 일부 작업은 완결되지 않음
• 팀 리더십 이양 후에도 여러 기여자들이 프로젝트 유지해왔으나, 장기적 비전 관리자는 부재하게 됨

Phase 4: Stasis

• 현재 jemalloc 업스트림 개발은 종료된 상태로, Meta 역시 내부 필요에 따라 별도의 방향성을 추구하게 됨
• 기존 코드베이스의 기술 부채가 커서 대대적 리팩토링이 선행 필요함
• 앞으로 개발에 재참여한다면 수백 시간의 사전 작업이 요구되나, 충분한 동기를 느끼지 못함
• 언제든 포크 기반의 새로운 프로젝트가 등장할 가능성은 있음

회고 및 교훈

• Valgrind 지원 제거는 외부 사용자 요구 파악 부족에서 발생한 실수임
• jemalloc의 안드로이드 채택, 교체 등 외부 움직임을 실시간으로 인지하지 못했던 경험이 있음
• 프로젝트는 공개적이었으나, 주도적 외부 기여자나 커뮤니티가 자리잡지 못함
• Firefox나 CMake 빌드 시스템 전환 등 외부 협업 시도는 여러 차례 실패함
• 경험상, 단순히 오픈만 한다고 지속가능한 독립 프로젝트가 되는 것은 아님

마무리

• jemalloc은 25년 넘게 가비지 컬렉션 지지자였던 저자에게도 특별한 경험이었음
• 다시 가비지 컬렉션 시스템 개발에 집중하고 있으나, jemalloc에 협력해준 모든 이들에게 깊은 감사함을 전함