내가 upstream 저장소를 아카이브하기로 한 결정을 이해하는 입장임. Meta를 떠나기 전에는 우리 Jemalloc 팀이 GitHub에 올라오는 온갖 이슈에 대응할 여력이 부족한 상황이었음(예를 들어 누군가 Itanium 환경에서 테스트가 통과하지 않는다고 이슈를 올린 적이 있었는데, 그게 내겐 약간 웃긴 사건이었음). 그래도 이런 상황을 보니 아쉽게 느끼는 감정임. 지금도 jemalloc이 내가 생각할 때 범용 malloc 구현체 중에서 가장 성능이 좋으면서도 쉽게 사용할 수 있는 선택지라고 느낌. TCMalloc도 훌륭하지만, bazel을 사용하지 않는다면 쓰기 정말 힘든 사례라고 생각함(요즘은 bazel 7.4.0에 cc_static_library가 추가되어 정적 라이브러리로 내보내기가 조금 쉬워졌지만, 여전히 그 점은 유의미하게 남아 있음). 나는 Qi에게 저장소를 다시 아카이빙하기 전에 마지막 6.0 릴리스를 한번 만들어줄 수 있는지 물어보려고 마음먹은 상태임. 마지막 릴리스라면 기본 설정을 조금 현대화해도 좋을 것 같다는 생각임. 예를 들어, 이름과 다르게 혼동을 주는 'cache oblivious' 설정을 기본값에서 비활성화해서 16 KiB size-class가 쓸데없이 20 KiB로 불어나는 문제를 막는 게 큰 개선점임. 이전의 선택(즉, Jason의 초기 결정)을 비난하려는 게 아니라, Qi 그리고 David와 당시 논의했을 때 일반적으로 TLB associativity가 지금보다 훨씬 낮았다는 점이 납득할 만한 이유였음. 비슷한 맥락에서, 기본 'page size'를 4 KiB에서 더 큰 값(16 KiB 정도)으로 키우는 것도 좋은 변화가 될 것임. 이러면 대형 size-class의 기준(여러 할당을 슬랩에 할당하다가 일정 크기 이상이면 각각 개별 범위에 할당하는 전환점)이 16 KiB에서 64 KiB로 올라가서 효과가 큼. 내가 Meta를 떠나기 전에 마지막으로 내부 주요 서비스에 이 변경을 적용하려고 검토한 적 있었는데, CPU 사용량이 몇 %나 절감되는 대신 RAM 단편화로 인한 소폭 메모리 증가가 있는 최적화였음. 이 외에도 몇 가지 바꾸고 싶은 점이 있음(예를 들면, metadata_thp 기본값을 'disabled'에서 'auto'로 변경, slabs의 extent 사이징을 페이지 사이즈의 정확한 배수에서 약 1% 낭비를 허용하는 대신 단편화를 줄이는 쪽으로 변경 등). 그래도 앞서 언급한 설정들이 가장 큰 변화가 될 것임
Itanium 테스트 스위트 실패 이슈를 등록했던 당사자가 바로 나임
이런 실제 경험담이나 내부자 인사이트가 있어야 Hacker News에 계속 오게 되는 원동력이라고 생각함. TCMalloc을 bazel 없이 쓰기 힘든 이유가 무엇인지 궁금증이 있음(정말로 궁금해서 질문하는 입장임)
이런 중요한 내부 지식이 공식 문서나 블로그 글 같은 확장된 자료로 공개되었으면 하는 바람임. 현재로서는 공식 문서가 너무 빈약하게 느껴지는 상황임. Meta 내부에서 이뤄진 수많은 작업의 노하우가 시간 지나 잊히기 전에 공유됐으면 좋겠다는 생각임
훌륭한 소프트웨어임에도 불구하고 빌드와 통합 과정이 복잡해서 제대로 활용되지 못하는 현실이 좀 아쉽게 느껴지는 상황임
‘Jemalloc 팀이 GitHub에 올라오는 랜덤 이슈 대응할 여력이 충분하지 않았다’는 부분을 언급하셨는데, 궁금한 점이 있음. Meta에 해당 프로젝트를 관리하는 충분한 인원이 있었음에도 이슈 관리는 원활하지 않았던 배경이 무엇인지 알고 싶음. 만약 상황을 잘못 이해하고 있다면 정정해주길 바람
Jason의 작업이 우리 업무에 얼마나 큰 영향을 주는지에 대한 이야기를 전하고 싶음. 우리 회사는 수억 건의 이미지/비디오를 매일 처리하는 꽤 규모가 있는 곳임. 시작 초기 몇 년 동안 메모리 단편화 문제로 엄청나게 고생했음. 그러던 어느 날 jemalloc을 도입했고, Dockerfile에서 딱 두 줄만 바꿨을 뿐인데 모든 문제가 해결되는 경험을 했음. 지금은 수백억 매출이 나는 회사로, 모든 서비스와 Dockerfile에 jemalloc을 사용 중임. 정말 마음 깊이 감사함을 전하는 마음임
실질적으로 많은 golang 기반 이미지 처리 서비스들이 jemalloc을 추천하거나 사용하고 있음. resize-images 주제에서 상위 3개 서비스 기준(2025-06-13 기준) imaginary는 이렇게 Dockerfile에서 사용 중이고, imgproxy는 아카이브된 문서를 참고로 imaginary repo 내에서도 논의됨. imagor도 이 위치에서 jemalloc을 쓰고 있는 상황임
진심으로 궁금해서 묻는 입장임(비꼬는 의도 전혀 없음): 혹시 기부도 했는지 궁금함. 돈으로 고마움을 표현하는 것이 최고의 감사 아니겠냐는 생각임
‘jemalloc이 Rust 바이너리에서 예상보다 빨리 제외됐다’는 의견에 대해, 실제로 그 이슈는 여러 원인 중 하나였던 점을 공유하고 싶음. 이 코멘트에서 관련 배경을 볼 수 있음. 그리고 jemalloc이 완전히 제거된 건 해당 이슈가 처음 제기된 후 무려 2년 뒤였음(참조: 이 PR)
저기에 언급된 여러 이슈 중 arm64에서 하드코딩된 페이지 사이즈 문제가 아직까지도 upstream에서 해결 안 된 부분이 흥미롭게 느껴짐. 이것 때문에 앱 개발자는 여러 개별 arm64 리눅스 바이너리를 따로 제공하거나 일부 플랫폼 지원을 포기해야 하는 상황임. 만약 동적 페이지 사이즈(성능을 위해 ftrace 스타일 바이너리 패치를 동적으로 적용)를 도입했다면 지금보다 많이 느려졌을지 궁금해지는 부분임
내가 수년간 만든 모든 게임 엔진에서 jemalloc을 꼭 쓰는 습관이 됐음. win32 환경에서는 기본 할당자보다 훨씬 빠르고, 모든 플랫폼에서 동일한 할당자를 쓰는 이점도 큼. FreeBSD에서 jemalloc 통합된 걸 계기로 알게 되었고, 그 이후로는 쭉 jemalloc만 사용 중임. jemalloc 덕분에 많은 게임 이용자들이 즐거움을 얻었다고 자부심 느끼는 입장임
window의 기본 allocator는 정말 별로라는 생각임. Jemalloc이 최고라는 확신임
좋은 글이라는 인상임 — Facebook(이제는 Meta)이 jemalloc 자체를 더는 쓰지 않는 건지, 아니면 유지보수만 하는 단계인지 궁금함. 혹시 tcmalloc이나 다른 allocator로 전환했을 가능성도 있는지 의문임. ‘Facebook 인프라 엔지니어링에서 코어 기술 투자보다는 ROI 중심으로 방점 이동했다’는 문장이 있었음
내가 Meta를 퇴사한 시점이 거의 2년 전인데(아직도 크게 달라지진 않았을 걸로 예상함), jemalloc은 여전히 Meta 내 모든 바이너리에 정적으로 링크되어 사용 중인 사실임. tcmalloc이나 다른 allocator로 쉽게 전환할 수 있냐는 질문에 대해, jemalloc은 회사 내부 생태계에 아주 깊이 결합되어 있으므로 생각보다 바꾸기 어렵다는 답변임. Strobelight 텔레메트리 플러밍에서부터, jemalloc에 맞춰 사용되는 수많은 extensions(예: 직접 커스텀 extent hook을 사용하는 수동 arena 등), 실제로 대부분의 애플리케이션이 jemalloc의 특성을 최대한 끌어내도록 설계된 진화 과정까지 모두 얽혀 있는 상황임
최근 큰 변화라면 jemalloc의 장기 메인테이너들이 전부 떠난 것임. 하지만 오히려 예전보다 Facebook 내부에서 이 프로젝트에 관심을 더 갖기 시작했고, 최근 일부 논란성 이슈를 거치면서 앞으로 Qi와 Jason, 그리고 외부 유저 입장 모두 고려하는 방향으로 나아갈 수 있길 기대하는 긍정적 전망임
Firefox부터 Facebook까지 오랜 기간 걸쳐 영향력 있던 이 일을 내가 함께할 수 있어 영광스러웠던 마음임
적절한 시점에 나 또한 이곳에 감사 인사를 남기고 싶은 심정임. 이번 글이 오늘 올라올 거라 예상하진 못했지만, 큰 여정의 작은 부분이라도 함께할 수 있어서 영광이었음. @je, qi, david와 당대 및 이후 기여자들에게도 고마움을 전하고 싶음
Facebook 내부에서 코어 기술에 계속 투자할 수 있도록 이끌었던 당신의 리더십이 최대한 결실을 맺었다고 생각함. GraphQL, PyTorch, React 같은 혁신이 가능했던 배경엔 이런 기반이 있었기 때문임
“불가능한 선택지 속에서 사람들은 1) 극도의 압박 속에서 안 좋은 결정을 하거나, 2) 극도의 압박 속에서 순응하거나, 3) 우회하는 길밖에 없다”는 FTA 인용문이 직장 분위기라고는 상상하기 힘든 모습임
내가 지난 2008년 이후 경험한 거의 모든 직장이 저런 모습이었다는 점이 씁쓸한 체험담임
jemalloc이 macOS 내에서 malloc/free를 LD_PRELOAD처럼 원활하게 오버라이드 할 수 있는 유일한 할당자라고 생각함(2020년경 기준). zone 기반 방식으로 쉽게 기본 할당자로 끼어들 수 있고, Apple 특유의 할당자 요구사항도 잘 맞추고 있음. 다른 third-party allocator들은 이 요구사항 때문에 종종 실패했었음
다만, 이 방식은 macOS 시스템 allocator가 내부 구조를 바꾸지 않는다는 가정 아래에서만 동작할 수 있기 때문에, 실제로 Apple이 변경해서 깨진 사례가 두 번 정도 있었던 걸로 기억함
mimalloc도 같은 방식으로 동작할 수 있는 걸로 아는데, 확신은 없음
jemalloc이 glibc의 malloc 대비 모든 면에서 개선된 부분이 보였고, 벤치마크 결과를 보면 항상 더 나은 성능을 보여주는 것으로 아는데, 그렇다면 왜 기본 allocator가 아닌지 외부자로서 궁금증이 있었음
FreeBSD에서는 이미 jemalloc이 기본임. malloc을 바꾸고 싶다면 libc도 같이 FreeBSD libc로 바꾸는 게 더 쉬울 것이고, 그러려면 kernel도 FreeBSD로 올리는 게 자연스러움. Facebook과 합병될 당시 우리 쪽 직원에게 jemalloc을 소개하면서 신나 했지만, 이미 FreeBSD라서 너무 당연하게 사용하는 문화였음
나는 allocator 엔지니어가 아니라 전문 의견은 아니지만, 예전에 OS allocator를 관리하는 엔지니어와 대화해본적 있음. 그분 말로는, 커스텀 allocator는 한 프로세스가 메모리 할당에서 압도적으로 유리해지는 대신, 시스템 전체의 할당 공정성은 악화되는 경향이 있음. 시스템 allocator 입장에서 개별 프로세스가 패턴을 다르게 가져가면 전체 최적화가 어려워짐. 그래서 대부분의 서비스 환경에서, '지금 내 프로세스만 중요하다'는 전제 하에 jemalloc이 많이 추천되는 것임
jemalloc이 기본 할당자가 안될 기술적 이유는 없다고 생각함. 실제로 FreeBSD에서는 디폴트임(기사에서 언급). 내 이해로는 이 이슈는 기술적인 것보다 정치적 성격이 더 크다고 봄
jemalloc은 실제 대규모 프로덕션에서 검증됐고 라이선스도 매우 자유롭고 성능도 입증된 사실임. 그런데 glibc malloc을 고수하는 이유가 대체 무엇인지, '이념적 순수성', 레거시 관성 외에 누가 이 상태에서 이득 보는지가 진심 궁금함. 왜 여전히 “호환성 때문”이라고 변명하는지 반문하고 싶은 심정임
예전에는 대안 allocator가 free된 메모리를 절대 OS로 다시 반환하지 않고 dirty page로 들고만 있었다는 문제가 컸음(이건 결국 개선됐지만, allocator의 우선순위 차이를 보여주는 대표 사례임). 그리고 실제로 대부분의 프로세스는 메인 쓰레드 하나만 돌리거나 거의 유휴 쓰레드뿐임. 멀티스레딩 최적화 allocator들은 이런 환경에서는 과잉이고 부담만 될 수 있음. 참고로, 커널이 페이지를 zero 처리하는 비용이나, 유저 프로세스가 자기 내부 재사용을 위해 zero하는 비용이나 실질적으로 차이가 없다는 점을 대부분 생각하지 않는다는 점도 언급하고 싶음
차라리 블로그 글 링크를 github 저장소에 추가해줬으면 하는 바람임. 앞으로 레포 방문하는 사람들이 이 맥락을 알고 참고하는 게 중요하다고 생각함
Hacker News 의견
내가 upstream 저장소를 아카이브하기로 한 결정을 이해하는 입장임. Meta를 떠나기 전에는 우리 Jemalloc 팀이 GitHub에 올라오는 온갖 이슈에 대응할 여력이 부족한 상황이었음(예를 들어 누군가 Itanium 환경에서 테스트가 통과하지 않는다고 이슈를 올린 적이 있었는데, 그게 내겐 약간 웃긴 사건이었음). 그래도 이런 상황을 보니 아쉽게 느끼는 감정임. 지금도 jemalloc이 내가 생각할 때 범용 malloc 구현체 중에서 가장 성능이 좋으면서도 쉽게 사용할 수 있는 선택지라고 느낌. TCMalloc도 훌륭하지만, bazel을 사용하지 않는다면 쓰기 정말 힘든 사례라고 생각함(요즘은 bazel 7.4.0에 cc_static_library가 추가되어 정적 라이브러리로 내보내기가 조금 쉬워졌지만, 여전히 그 점은 유의미하게 남아 있음). 나는 Qi에게 저장소를 다시 아카이빙하기 전에 마지막 6.0 릴리스를 한번 만들어줄 수 있는지 물어보려고 마음먹은 상태임. 마지막 릴리스라면 기본 설정을 조금 현대화해도 좋을 것 같다는 생각임. 예를 들어, 이름과 다르게 혼동을 주는 'cache oblivious' 설정을 기본값에서 비활성화해서 16 KiB size-class가 쓸데없이 20 KiB로 불어나는 문제를 막는 게 큰 개선점임. 이전의 선택(즉, Jason의 초기 결정)을 비난하려는 게 아니라, Qi 그리고 David와 당시 논의했을 때 일반적으로 TLB associativity가 지금보다 훨씬 낮았다는 점이 납득할 만한 이유였음. 비슷한 맥락에서, 기본 'page size'를 4 KiB에서 더 큰 값(16 KiB 정도)으로 키우는 것도 좋은 변화가 될 것임. 이러면 대형 size-class의 기준(여러 할당을 슬랩에 할당하다가 일정 크기 이상이면 각각 개별 범위에 할당하는 전환점)이 16 KiB에서 64 KiB로 올라가서 효과가 큼. 내가 Meta를 떠나기 전에 마지막으로 내부 주요 서비스에 이 변경을 적용하려고 검토한 적 있었는데, CPU 사용량이 몇 %나 절감되는 대신 RAM 단편화로 인한 소폭 메모리 증가가 있는 최적화였음. 이 외에도 몇 가지 바꾸고 싶은 점이 있음(예를 들면, metadata_thp 기본값을 'disabled'에서 'auto'로 변경, slabs의 extent 사이징을 페이지 사이즈의 정확한 배수에서 약 1% 낭비를 허용하는 대신 단편화를 줄이는 쪽으로 변경 등). 그래도 앞서 언급한 설정들이 가장 큰 변화가 될 것임
Itanium 테스트 스위트 실패 이슈를 등록했던 당사자가 바로 나임
이런 실제 경험담이나 내부자 인사이트가 있어야 Hacker News에 계속 오게 되는 원동력이라고 생각함. TCMalloc을 bazel 없이 쓰기 힘든 이유가 무엇인지 궁금증이 있음(정말로 궁금해서 질문하는 입장임)
이런 중요한 내부 지식이 공식 문서나 블로그 글 같은 확장된 자료로 공개되었으면 하는 바람임. 현재로서는 공식 문서가 너무 빈약하게 느껴지는 상황임. Meta 내부에서 이뤄진 수많은 작업의 노하우가 시간 지나 잊히기 전에 공유됐으면 좋겠다는 생각임
훌륭한 소프트웨어임에도 불구하고 빌드와 통합 과정이 복잡해서 제대로 활용되지 못하는 현실이 좀 아쉽게 느껴지는 상황임
‘Jemalloc 팀이 GitHub에 올라오는 랜덤 이슈 대응할 여력이 충분하지 않았다’는 부분을 언급하셨는데, 궁금한 점이 있음. Meta에 해당 프로젝트를 관리하는 충분한 인원이 있었음에도 이슈 관리는 원활하지 않았던 배경이 무엇인지 알고 싶음. 만약 상황을 잘못 이해하고 있다면 정정해주길 바람
Jason의 작업이 우리 업무에 얼마나 큰 영향을 주는지에 대한 이야기를 전하고 싶음. 우리 회사는 수억 건의 이미지/비디오를 매일 처리하는 꽤 규모가 있는 곳임. 시작 초기 몇 년 동안 메모리 단편화 문제로 엄청나게 고생했음. 그러던 어느 날 jemalloc을 도입했고, Dockerfile에서 딱 두 줄만 바꿨을 뿐인데 모든 문제가 해결되는 경험을 했음. 지금은 수백억 매출이 나는 회사로, 모든 서비스와 Dockerfile에 jemalloc을 사용 중임. 정말 마음 깊이 감사함을 전하는 마음임
실질적으로 많은 golang 기반 이미지 처리 서비스들이 jemalloc을 추천하거나 사용하고 있음. resize-images 주제에서 상위 3개 서비스 기준(2025-06-13 기준) imaginary는 이렇게 Dockerfile에서 사용 중이고, imgproxy는 아카이브된 문서를 참고로 imaginary repo 내에서도 논의됨. imagor도 이 위치에서 jemalloc을 쓰고 있는 상황임
진심으로 궁금해서 묻는 입장임(비꼬는 의도 전혀 없음): 혹시 기부도 했는지 궁금함. 돈으로 고마움을 표현하는 것이 최고의 감사 아니겠냐는 생각임
‘jemalloc이 Rust 바이너리에서 예상보다 빨리 제외됐다’는 의견에 대해, 실제로 그 이슈는 여러 원인 중 하나였던 점을 공유하고 싶음. 이 코멘트에서 관련 배경을 볼 수 있음. 그리고 jemalloc이 완전히 제거된 건 해당 이슈가 처음 제기된 후 무려 2년 뒤였음(참조: 이 PR)
내가 수년간 만든 모든 게임 엔진에서 jemalloc을 꼭 쓰는 습관이 됐음. win32 환경에서는 기본 할당자보다 훨씬 빠르고, 모든 플랫폼에서 동일한 할당자를 쓰는 이점도 큼. FreeBSD에서 jemalloc 통합된 걸 계기로 알게 되었고, 그 이후로는 쭉 jemalloc만 사용 중임. jemalloc 덕분에 많은 게임 이용자들이 즐거움을 얻었다고 자부심 느끼는 입장임
좋은 글이라는 인상임 — Facebook(이제는 Meta)이 jemalloc 자체를 더는 쓰지 않는 건지, 아니면 유지보수만 하는 단계인지 궁금함. 혹시 tcmalloc이나 다른 allocator로 전환했을 가능성도 있는지 의문임. ‘Facebook 인프라 엔지니어링에서 코어 기술 투자보다는 ROI 중심으로 방점 이동했다’는 문장이 있었음
내가 Meta를 퇴사한 시점이 거의 2년 전인데(아직도 크게 달라지진 않았을 걸로 예상함), jemalloc은 여전히 Meta 내 모든 바이너리에 정적으로 링크되어 사용 중인 사실임. tcmalloc이나 다른 allocator로 쉽게 전환할 수 있냐는 질문에 대해, jemalloc은 회사 내부 생태계에 아주 깊이 결합되어 있으므로 생각보다 바꾸기 어렵다는 답변임. Strobelight 텔레메트리 플러밍에서부터, jemalloc에 맞춰 사용되는 수많은 extensions(예: 직접 커스텀 extent hook을 사용하는 수동 arena 등), 실제로 대부분의 애플리케이션이 jemalloc의 특성을 최대한 끌어내도록 설계된 진화 과정까지 모두 얽혀 있는 상황임
최근 큰 변화라면 jemalloc의 장기 메인테이너들이 전부 떠난 것임. 하지만 오히려 예전보다 Facebook 내부에서 이 프로젝트에 관심을 더 갖기 시작했고, 최근 일부 논란성 이슈를 거치면서 앞으로 Qi와 Jason, 그리고 외부 유저 입장 모두 고려하는 방향으로 나아갈 수 있길 기대하는 긍정적 전망임
Meta는 여전히 자체 포크 버전을 여기서 활발히 개발 중임
Firefox부터 Facebook까지 오랜 기간 걸쳐 영향력 있던 이 일을 내가 함께할 수 있어 영광스러웠던 마음임
적절한 시점에 나 또한 이곳에 감사 인사를 남기고 싶은 심정임. 이번 글이 오늘 올라올 거라 예상하진 못했지만, 큰 여정의 작은 부분이라도 함께할 수 있어서 영광이었음. @je, qi, david와 당대 및 이후 기여자들에게도 고마움을 전하고 싶음
Facebook 내부에서 코어 기술에 계속 투자할 수 있도록 이끌었던 당신의 리더십이 최대한 결실을 맺었다고 생각함. GraphQL, PyTorch, React 같은 혁신이 가능했던 배경엔 이런 기반이 있었기 때문임
“불가능한 선택지 속에서 사람들은 1) 극도의 압박 속에서 안 좋은 결정을 하거나, 2) 극도의 압박 속에서 순응하거나, 3) 우회하는 길밖에 없다”는 FTA 인용문이 직장 분위기라고는 상상하기 힘든 모습임
jemalloc이 macOS 내에서 malloc/free를 LD_PRELOAD처럼 원활하게 오버라이드 할 수 있는 유일한 할당자라고 생각함(2020년경 기준). zone 기반 방식으로 쉽게 기본 할당자로 끼어들 수 있고, Apple 특유의 할당자 요구사항도 잘 맞추고 있음. 다른 third-party allocator들은 이 요구사항 때문에 종종 실패했었음
다만, 이 방식은 macOS 시스템 allocator가 내부 구조를 바꾸지 않는다는 가정 아래에서만 동작할 수 있기 때문에, 실제로 Apple이 변경해서 깨진 사례가 두 번 정도 있었던 걸로 기억함
mimalloc도 같은 방식으로 동작할 수 있는 걸로 아는데, 확신은 없음
jemalloc이 glibc의 malloc 대비 모든 면에서 개선된 부분이 보였고, 벤치마크 결과를 보면 항상 더 나은 성능을 보여주는 것으로 아는데, 그렇다면 왜 기본 allocator가 아닌지 외부자로서 궁금증이 있었음
FreeBSD에서는 이미 jemalloc이 기본임. malloc을 바꾸고 싶다면 libc도 같이 FreeBSD libc로 바꾸는 게 더 쉬울 것이고, 그러려면 kernel도 FreeBSD로 올리는 게 자연스러움. Facebook과 합병될 당시 우리 쪽 직원에게 jemalloc을 소개하면서 신나 했지만, 이미 FreeBSD라서 너무 당연하게 사용하는 문화였음
나는 allocator 엔지니어가 아니라 전문 의견은 아니지만, 예전에 OS allocator를 관리하는 엔지니어와 대화해본적 있음. 그분 말로는, 커스텀 allocator는 한 프로세스가 메모리 할당에서 압도적으로 유리해지는 대신, 시스템 전체의 할당 공정성은 악화되는 경향이 있음. 시스템 allocator 입장에서 개별 프로세스가 패턴을 다르게 가져가면 전체 최적화가 어려워짐. 그래서 대부분의 서비스 환경에서, '지금 내 프로세스만 중요하다'는 전제 하에 jemalloc이 많이 추천되는 것임
jemalloc이 기본 할당자가 안될 기술적 이유는 없다고 생각함. 실제로 FreeBSD에서는 디폴트임(기사에서 언급). 내 이해로는 이 이슈는 기술적인 것보다 정치적 성격이 더 크다고 봄
jemalloc은 실제 대규모 프로덕션에서 검증됐고 라이선스도 매우 자유롭고 성능도 입증된 사실임. 그런데 glibc malloc을 고수하는 이유가 대체 무엇인지, '이념적 순수성', 레거시 관성 외에 누가 이 상태에서 이득 보는지가 진심 궁금함. 왜 여전히 “호환성 때문”이라고 변명하는지 반문하고 싶은 심정임
예전에는 대안 allocator가 free된 메모리를 절대 OS로 다시 반환하지 않고 dirty page로 들고만 있었다는 문제가 컸음(이건 결국 개선됐지만, allocator의 우선순위 차이를 보여주는 대표 사례임). 그리고 실제로 대부분의 프로세스는 메인 쓰레드 하나만 돌리거나 거의 유휴 쓰레드뿐임. 멀티스레딩 최적화 allocator들은 이런 환경에서는 과잉이고 부담만 될 수 있음. 참고로, 커널이 페이지를 zero 처리하는 비용이나, 유저 프로세스가 자기 내부 재사용을 위해 zero하는 비용이나 실질적으로 차이가 없다는 점을 대부분 생각하지 않는다는 점도 언급하고 싶음
차라리 블로그 글 링크를 github 저장소에 추가해줬으면 하는 바람임. 앞으로 레포 방문하는 사람들이 이 맥락을 알고 참고하는 게 중요하다고 생각함