Alocadores de Memória de Alta Performance: jemalloc e mimalloc no Linux

A substituição do alocador padrão da glibc por jemalloc ou mimalloc reduz a latência P99 em até 70% e corta o consumo de RAM.

Em runtimes multithreaded de alta vazão, a contenção de mutexes globais torna o alocador o principal gargalo do sistema operacional.

A maioria dos serviços em produção confia cegamente no malloc padrão da biblioteca C. Em servidores modernos com dezenas de núcleos, essa escolha causa travamentos e estouro de memória física.

Por que o ptmalloc da glibc colapsa sob alta concorrência

O ptmalloc3 da GNU C Library falha em alta concorrência devido à contenção de locks em suas arenas e à consolidação síncrona de memória. Quando centenas de threads solicitam memória simultaneamente, o travamento bloqueia a execução paralela das CPUs.

Historicamente derivado do alocador de Wolfram Gloger e Doug Lea, o ptmalloc3 divide o heap em arenas. O Manual da GNU C Library detalha esse limite. Em 64 bits, o runtime cria até 8 × ncores arenas.

Cada arena possui um pthread_mutex_t dedicado. Quando o total de threads ativas supera as arenas disponíveis, ocorre contenção no pthread_mutex_trylock. As threads sem arena livre travam na fila do mutex.

Além disso, pequenos blocos em fastbins exigem consolidação periódica via malloc_consolidate. Esse processo varre blocos adjacentes para fundi-los. Ele interrompe a alocação na arena inteira, gerando picos imprevisíveis na latência P99.9.

A física do hardware: linhas de cache, falso compartilhamento e TLB misses

A alocação de memória afeta a performance na hierarquia de cache L1/L2/L3 e nas tabelas de paginação do processador. Alocações mal alinhadas geram invalidação contínua de linhas de cache de 64 bytes pelo protocolo MESI dos processadores modernos.

Quando duas threads manipulam blocos vizinhos na mesma linha de 64 bytes, ocorre o false sharing. O processador transita a linha entre os estados Modified e Invalid seguidamente. Esse ciclo satura o barramento de interconexão entre soquetes NUMA.

O segundo gargalo reside no esgotamento do Translation Lookaside Buffer (TLB). O TLB armazena as traduções de endereços virtuais para físicos. Em páginas padrão de 4 KiB, cobrir 1 GiB de memória exige 262.144 entradas, estourando a capacidade do TLB de nível 2.

A alocação em blocos uniformes (size classes) previne a fragmentação interna. Ela assegura que objetos alocados por threads distintas nunca compartilhem a mesma linha de cache física.

TCMalloc: a segregação em três camadas concebida pelo Google

O TCMalloc resolveu a contenção global separando o heap em cache local por thread, lista central e heap de páginas. Essa arquitetura, criada por Sanjay Ghemawat e Sanjay Menage, eliminou quase todos os locks no caminho crítico de alocação em C++.

Segundo a Documentação de Arquitetura do TCMalloc, o alocador opera em três níveis hierárquicos:

1. ThreadCache: Cada thread mantém um cache privado sem locks com aproximadamente 80 classes de tamanho. Alocações de até 256 KiB são atendidas instantaneamente sem instruções atômicas.
2. CentralFreeList / TransferCache: Quando o cache esgota uma classe de tamanho, ele requisita um lote de objetos da lista central. A transferência em lote amortiza o custo do lock.
3. PageHeap: Gerencia a memória virtual do sistema operacional em vãos de páginas (Spans) de 4 KiB ou 8 KiB. Alocações grandes (> 256 KiB) vão diretamente ao PageHeap.

 +-------------------------------------------------------------+
 | Thread Local Cache (Size Classes: 8B a 256KB) - Sem Locks   |
 +-------------------------------------------------------------+
                               | (Transferência em Lote / Batch)
                               v
 +-------------------------------------------------------------+
 | CentralFreeList / TransferCache (Locks por Size Class)      |
 +-------------------------------------------------------------+
                               | (Alocação de Spans Contíguos)
                               v
 +-------------------------------------------------------------+
 | PageHeap (Páginas do Kernel via mmap / madvise)             |
 +-------------------------------------------------------------+

O TCMalloc provou que transferências em lote resolvem o throughput em microsserviços distribuídos. Contudo, sua retenção passiva de páginas em memória virtual pode elevar o RSS em processos de longa duração.

jemalloc: arenas per-CPU, árvores de extents e decaimento contínuo

O jemalloc elimina a fragmentação de longo prazo e estabiliza o consumo de memória através de purgas contínuas no tempo. Criado por Jason Evans para o FreeBSD e adotado no ecossistema Rust e Redis, ele é o padrão da indústria para processos de alta escala.

Conforme apresentado no artigo seminal de Jason Evans (BSDCan 2006), o jemalloc estrutura a memória em pilares fundamentais:

• Arenas per-CPU com rseq: O jemalloc moderno indexa arenas pela CPU que executa a thread via Restartable Sequences (rseq(2)). Isso elimina a contenção de locks mesmo com milhares de threads simultâneas.
• Extents em Árvores Rubro-Negras: Os blocos de memória contígua são rastreados em árvores balanceadas ordenadas por endereço e tamanho, garantindo alocação e coalescência em tempo O(log n).
• Decaimento Suave (dirty_decay_ms): Páginas liberadas não são devolvidas ao kernel em picos abruptos. O jemalloc aplica uma curva de decaimento suave, devolvendo páginas limpas via madvise(2) de forma contínua.

A purga baseada em tempo evita tempestades de chamadas de sistema. Em vez de travar a thread para devolver memória, o jemalloc programa o descarte gradual das páginas inativas.

mimalloc: o estado da arte com Free List Sharding

O mimalloc atinge o menor tempo de execução da categoria ao eliminar instruções atômicas e empacotar metadados em segmentos de 64 KiB. O alocador foi criado por Daan Leijen na Microsoft Research. Ele executa o caminho feliz em apenas 4 ciclos de clock.

A grande inovação do mimalloc é o Free List Sharding. Em alocadores convencionais, uma única lista livre atende alocações locais e desalocações de outras threads, exigindo operações atômicas custosas.

O mimalloc divide a lista livre de cada página em três listas independentes:

1. free list local: Manipulada apenas pela thread dona. É uma lista encadeada simples que consome apenas 2 a 3 instruções em Assembly x86-64 sem barreira de memória.
2. thread_free list atômica: Utilizada exclusivamente quando uma thread externa libera um bloco alocado por esta página (cross-thread freeing). A inserção usa uma única operação atômica de ponteiro.
3. local_free list: Quando a lista free esgota, a thread dona move todos os itens acumulados na thread_free para a local_free com uma única instrução atômica, restaurando a lista local.

Os metadados das páginas ficam embutidos no cabeçalho do segmento alinhado de 4 MiB ou 32 MiB. O mimalloc aplica uma máscara de bits no endereço (ptr & ~(SEGMENT_SIZE - 1)). Essa operação descobre os metadados sem consultas a tabelas globais.

Comparativo arquitetural: ptmalloc3 vs TCMalloc vs jemalloc vs mimalloc

A escolha do alocador depende do padrão de acesso à memória, da concorrência e do ciclo de vida das threads da aplicação. Cada projeto equilibra throughput absoluto, uso de CPU e retenção de RSS de forma distinta.

Para sistemas com milhões de pequenas alocações efêmeras e foco em latência pura, o mimalloc entrega o menor custo de CPU. Para bancos de dados e servidores com retenção mista e necessidade de profiling contínuo, o jemalloc permanece a escolha mais estável.

Caso prático: Rust, Tokio e Gateways de Alta Vazão

Runtimes assíncronos baseados em tarefas verdes sofrem forte degradação com alocadores padrão porque tarefas migram entre threads de trabalho continuamente. Quando a tarefa aloca na thread A e desaloca na thread B, o cross-thread freeing sobrecarrega a glibc.

No ecossistema Rust, definir um alocador global de alto desempenho exige apenas adicionar a dependência e registrar o ponteiro estático no binário:

// Cargo.toml
// [dependencies]
// mimalloc = { version = "0.1", default-features = false }

use mimalloc::MiMalloc;

#[global_allocator]
static GLOBAL: MiMalloc = MiMalloc;

#[tokio::main]
async fn main() {
    // Gateway assíncrono Tokio executando com mimalloc
    println!("Runtime inicializado com alocador de sub-nanosegundo.");
}

No MaxVision Code, a substituição da glibc pelo mimalloc elevou o throughput de 142.000 para 234.000 req/s (+64%). Ao mesmo tempo, reduziu a latência P99 de 18,4 ms para 5,4 ms (-70%).

O ganho decorre da eliminação da contenção nos pools de workers do Tokio. Como as tarefas migram livremente entre os núcleos, as filas atômicas do mimalloc absorvem as desalocações cruzadas sem bloquear os núcleos adjacentes.

Diagnóstico e profiling: detectando memory bloat com jeprof

Vazamentos de memória reais diferem de fragmentação de heap e de retenção passiva de páginas no sistema operacional. O jemalloc inclui um profiler estatístico por amostragem de Poisson. Ele mapeia alocações ativas em produção com overhead inferior a 1,5% de CPU.

Para habilitar a amostragem em tempo de execução sem recompilar o binário, basta exportar a variável de ambiente MALLOC_CONF:

# Habilita profiling de heap por amostragem e decaimento de páginas de 1 segundo
export MALLOC_CONF="prof:true,prof_active:true,prof_prefix:jeprof.out,lg_prof_sample:19,dirty_decay_ms:1000,muzzy_decay_ms:1000"

# Executa o binário do serviço
./meu-servico-alta-vazao

A geração do relatório de rotinas alocadoras no terminal é executada diretamente pelo utilitário jeprof:

# Analisa o dump de memória e exibe as principais rotinas consumidoras
jeprof --show_bytes --top ./meu-servico-alta-vazao jeprof.out.*.heap

Esse procedimento revela imediatamente se o aumento do RSS provém de retenção real de ponteiros ou de fragmentação de páginas no alocador.

Guia de decisão: qual alocador escolher para sua infraestrutura

A escolha entre jemalloc e mimalloc deve guiar-se pela arquitetura do software, pela duração dos processos e pela necessidade de telemetria em tempo real. Não existe alocador universalmente superior em todos os cenários.

• Escolha o mimalloc quando: a aplicação for escrita em Rust, C++ ou Go (via CGO), com alta taxa de alocação de pequenas estruturas de dados em threads efêmeras, pipelines de parsing de IA, gateways HTTP/gRPC ou quando a prioridade absoluta for latência média e P99 mínima.
• Escolha o jemalloc quando: o sistema for um banco de dados de longa execução (como Redis, ScyllaDB ou motores de busca vetorial), onde o footprint de RSS precisa ser devolvido rigorosamente ao kernel e a telemetria com jeprof for obrigatória para governança.
• Mantenha o ptmalloc3 apenas quando: a aplicação for estritamente monothread, possuir ciclos de vida inferiores a 1 segundo ou operar em contêineres mínimos onde a sobrecarga de binários adicionais não justifique a substituição.

Configurar o alocador correto nas variáveis de ambiente transforma a eficiência da infraestrutura. O ajuste elimina gargalos antes que cheguem a produção.