jemalloc 사후 회고문

• jemalloc 의 개발을 주도한 Jason Evans가 직접 쓴 회고록으로, 약 20년에 걸친 jemalloc 개발의 여정을 5단계로 나누어 돌아보며, 성공과 실패, 오픈소스 프로젝트의 한계와 기업 내 변화로 인한 쇠퇴 과정을 진솔하게 기록한 글
• jemalloc 메모리 할당기는 2004년부터 시작되어 약 20년간 널리 사용되었지만, 최근 Meta의 내부 변화로 인해 공식적 개발이 중단됨
• 초기 FreeBSD 통합, Firefox 성능 문제 해결, Facebook의 대규모 채택 등 여러 단계에서 성능 최적화와 포팅 경험을 축적함
• 저장 공간 단편화 문제와 확장성 문제 등 다양한 도전을 거치면서, 성능 향상 및 통계 수집, 테스트 인프라 등 다양한 기능이 추가됨
• Meta로의 기업 문화 변화와 함께 기술 투자 감소, 핵심 유지보수 인력 부재로 장기 개발이 중단됨
• Valgrind 제거나 외부 사용자 피드백 부재 등 오픈소스 생태계에서의 단절이 구조적 한계로 작용했음
• 앞으로 포크(fork) 를 통한 새로운 발전 가능성은 열려 있으나, 공식적인 메인 개발은 더 이상 진행되지 않을 전망임

jemalloc 개요

• 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의 거대한 텔레메트리 시스템 덕분에 성능 최적화와 회귀 방지에 큰 도움이 됨
• 3.x: 테스트 인프라 및 Valgrind 지원 도입
• 4.x: 디케이 기반 메모리 해제(decay-based purging), JSON 통계 추가
• 5.x: chunk에서 extent 기반 설계로 변경, 2MiB huge page 활용 기반 마련
• Facebook 내부의 telemetry 기반 성능 분석이 최적화에 결정적 역할 수행
• 5.0.0 버전에서 Valgrind 지원 제거는 내부에서 사용하지 않아 결정했으나, Rust 개발자 등 외부에서 반발이 강했음
• 이후 Facebook/Meta의 조직 변화로 jemalloc 팀이 축소되고, 핵심 기술 투자보다 효율성 중심의 사업 전략으로 전환됨
• 이에 따라 Huge Page Allocation과 같은 대형 기능의 개발이 정체, 일부 작업은 완결되지 않음
• 2017년 Evans 퇴사 이후, Qi Wang 주도로 수년간 개발 유지
• 팀 리더십 이양 후에도 여러 기여자들이 프로젝트 유지해왔으나, 장기적 비전 관리자는 부재하게 됨

Phase 4: Stasis (정지 상태)

• 현재 jemalloc 업스트림 개발은 종료된 상태로, Meta 역시 내부 필요에 따라 별도의 방향성을 추구하게 됨
• 기존 코드베이스의 기술 부채가 커서 대대적 리팩토링이 선행 필요함
• Facebook/Meta의 요구사항과 외부 유저의 요구가 더 이상 일치하지 않음
• 향후 개발 재개 시 수백 시간 이상의 기술 부채 정리가 선행되어야 하며, 본인은 의욕 없음
• dev 브랜치 혹은 5.3.0 기준으로 외부 포크는 가능하여, 언제든 포크 기반의 새로운 프로젝트가 등장할 가능성은 있음

회고 및 교훈

• Valgrind 지원 제거로 생긴 갈등은 외부 사용처 파악 부족에서 기인
• Android에서 jemalloc이 사용 중이었다는 사실도 2년이 지나서야 알게 됨
• 프로젝트는 GitHub에서 완전히 공개되었지만, 외부 조직에서의 핵심 기여자가 지속되지 못함
  • Firefox의 Mike Hommey나 CMake 전환 시도도 모두 미완에 그침
• 경험상, 단순히 오픈만 한다고 지속가능한 독립 프로젝트가 되는 것은 아님
• 오픈소스는 공개만으로 유지되지 않으며, 핵심 기여자 육성과 거버넌스 확보가 필수적임을 강조

마무리 발언

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