https://lkic1625.github.io/blog/allocator/Recent content in Allocator on Hammer's BlogHugoko-kr© 조원빈 - All rights reservedWed, 21 Oct 2026 13:01:48 +0900https://lkic1625.github.io/os-memory-allocation/Wed, 21 Oct 2026 13:01:48 +0900https://lkic1625.github.io/os-memory-allocation/<h2 id="allocation-관련-정리">Allocation 관련 정리</h2> <p>Allocator는 기본적으로, 4가지 정도 존재한다.</p> <ol> <li>얼마나 빨리 할당할 수 있는가, <ol> <li>매번 커널 진입이 아닌, 미리 확보한 메모리를 Free List 를 통해 활요하는 Fast Path를 이용</li> </ol> </li> <li>얼마나 적은 메모리를 낭비하는가 <ol> <li>단편화 문제를 어떻게 해결하는가, 실제 요청보다 더 큰 Block을 할당하거나, 여유 공간은 충분하지만 연속 공간을 효율적으로 반환하기 어려운 경우</li> </ol> </li> <li>동시성 확보를 위한 방식 <ol> <li>여러 스레드가 요청하는 경우의 contention 관리</li> </ol> </li> <li>언제 메모리를 반환할 것인가. <ol> <li>실제 메모리가 다시 쓰일 확률이 높다면 이를 가지고 재사용하는 것이 합당하다 이 네 가지를 통해 실제 설계 철학들을 엿볼 수 있다. 또한, 현대의 메모리 할당기가 서로 배타적인 구현을 하는 것이 아니고, 각 방법에서 핵심 설계 관점을 다르게 보는 것이다.</li> </ol> </li> </ol> <table> <thead> <tr> <th>Allocator</th> <th>핵심 설계 관점</th> <th>대표적인 기법</th> </tr> </thead> <tbody> <tr> <td>glibc malloc (ptmalloc 계열)</td> <td>범용성, 호환성</td> <td>Arena, Thread Cache</td> </tr> <tr> <td>jemalloc</td> <td>단편화 관리, 메모리 사용량 제어</td> <td>Multiple Arenas, Decay, Purging</td> </tr> <tr> <td>TCMalloc</td> <td>높은 병렬성과 빠른 할당</td> <td>Per-CPU Cache, rseq, Hugepage-aware Allocation</td> </tr> <tr> <td>mimalloc</td> <td>낮은 경합, Locality, 메모리 효율</td> <td>Free-list Sharding, Eager Purging</td> </tr> <tr> <td>snmalloc</td> <td>Cross-thread Free의 확장성</td> <td>Message Passing</td> </tr> <tr> <td>Scudo</td> <td>Heap 메모리 안전성</td> <td>Metadata 검증, Quarantine, Randomization</td> </tr> </tbody> </table> <h3 id="tcache-glibc">tcache, glibc</h3> <pre tabindex="0"><code>Thread 1 ── tcache ──┐ Thread 2 ── tcache ──┼── Arenas ── OS Thread 3 ── tcache ──┘ </code></pre><p>객체를 할당하고 해제하는데 필요한 정보를 스레드 별로 두어, lock 집중을 막는 방식</p>