glibc alocação de memória: arenas e depuração

Question

Versões recentes de glibc (de 2.12?) têm sintonizáveis MALLOC_ARENA_MAX e MALLOC_PER_THREAD.

Perguntas:

1. Existe alguma diferença entre MALLOC_PER_THREAD = 0 e MALLOC_ARENA_MAX = 1? O MALLOC_PER_THREAD ainda é suportado no último glibc?

2. Arenas aumentam o uso de memória virtual: são adequados para kernels de 32 bits?

3. Eles também são adequados para uma CPU principal (convidados virtuais)?

4. Se eu habilitar verificações de memória com

MALLOC_CHECK_=3

o glibc usa um alocador básico de depuração ou o padrão?

Era uma vez eu li o glibc com algum tipo de depuração, use um alocador básico ao invés do regular ... mas não consigo encontrar os documentos.

    

Answer 1

1. Pelo que entendi, MALLOC_PER_THREAD era um botão de configuração temporária fornecido no RHEL para habilitar o novo alocador por encadeamento (consulte as notas de lançamento do CentOS correspondentes para detalhes). Não está mais disponível nas versões atuais de glibc e o novo alocador se tornou o padrão em 2.15 (acho). Definir MALLOC_ARENA_MAX=1 significa que só pode haver uma arena, que tem um efeito semelhante, mas provavelmente não é estritamente equivalente, já que outras partes do "novo" alocador ainda estão ativas neste caso.

2. Sim, eles são adequados para kernels de 32 bits; mas o ajuste padrão é diferente ( M_ARENA_TEST é 2 em sistemas de 32 bits, 8 em outros).

3. Provavelmente não há muito sentido em usar arenas múltiplas em sistemas single-core, mas o ajuste padrão deve resolver isso (o limite rígido para arenas é geralmente um múltiplo do número de CPUs disponíveis).

4. M_CHECK_ACTION=3 é o padrão atualmente, portanto, ativar as verificações de memória usa o alocador padrão.

A documentação em nível de usuário para isso está em man mallopt .

glibc 2.26 deve ter um novo cache por thread , tcache , mas isso obviamente demorará um pouco antes de estar disponível nas distribuições . (A data de lançamento planejada é 01 de agosto deste ano).