Como funcionam os alocadores de memória do STD C?
Um pequeno artigo que explica por que seu programa jamais retorna memória ao sistema operacional enquanto está em execução.
[ Hits: 38.982 ]
Por: Ronaldo Faria Lima em 28/06/2004
Como funcionam os alocadores de memória?
Os alocadores de memória do Standard C têm os seguintes protótipos:
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void *realloc(void *ptr, size_t size);
Todos devolvem um ponteiro para a área de memória alocada ou um ponteiro inválido informando que não existe mais memória disponível para se alocada. Aqui cabe uma primeira dica: nunca confie que estas funções vão sempre devolver um ponteiro válido. Sempre verifique o retorno das funções a fim de constatar que a memória requerida foi realmente alocada. É comum problemas onde o programa é executado em um ambiente restritivo onde a quantidade de memória que pode ser alocada por um processo é limitada por um administrador de sistema. Esta situação é muito comum em ambientes de produção Unix.
Visto os protótipos das funções, aqui vão como as mesmas funcionam:
Quando se fala em alocação de memória, estamos falando, na verdade, de como interfacear seu programa com o sistema operacional, pois efetivamente quem lhe dará memória é o sistema operacional. Estas funções, conforme dito anteriormente, são abstrações que encobrem a forma como irão chamar o sistema operacional a fim de obter mais memória para o seu programa. Porém, para qualquer implementação da biblioteca Standard C, estas funções têm um comportamento igual: o gerenciamento da lista livre.
void *calloc(size_t nmemb, size_t size);
void *malloc(size_t size);
void *realloc(void *ptr, size_t size);
Todos devolvem um ponteiro para a área de memória alocada ou um ponteiro inválido informando que não existe mais memória disponível para se alocada. Aqui cabe uma primeira dica: nunca confie que estas funções vão sempre devolver um ponteiro válido. Sempre verifique o retorno das funções a fim de constatar que a memória requerida foi realmente alocada. É comum problemas onde o programa é executado em um ambiente restritivo onde a quantidade de memória que pode ser alocada por um processo é limitada por um administrador de sistema. Esta situação é muito comum em ambientes de produção Unix.
Visto os protótipos das funções, aqui vão como as mesmas funcionam:
- calloc aloca blocos de memória que contém nmemb ítens de tamanho size bytes. Esta função é excelente para alocar vetores de estruturas de dados.
- malloc aloca um bloco contíguo de memória de tamanho size bytes. É a função mais popular da biblioteca Standard C.
- realloc tenta redimensionar a memória que é apontada por ptr para o tamanho size bytes. Se ptr for um ponteiro nulo, realloc funciona exatamente igual a malloc.
Quando se fala em alocação de memória, estamos falando, na verdade, de como interfacear seu programa com o sistema operacional, pois efetivamente quem lhe dará memória é o sistema operacional. Estas funções, conforme dito anteriormente, são abstrações que encobrem a forma como irão chamar o sistema operacional a fim de obter mais memória para o seu programa. Porém, para qualquer implementação da biblioteca Standard C, estas funções têm um comportamento igual: o gerenciamento da lista livre.
Páginas do artigo
1. Uma introdução ao sistema de alocação de memória do STD C2. Como funcionam os alocadores de memória?
3. O que é a lista livre?
4. O que acontece quando libero memória?
5. Conclusão
Outros artigos deste autor
Programando com uma granada de mão: uma visão da linguagem C
Leitura recomendada
Linguagem C - Funções Variádicas
A duplicação do buffer de saída na chamada de sistema fork() do Linux
Estudando recursividade direta e indireta
Comentários
[1] Comentário enviado por espinafre em 29/06/2004 - 11:28h
Bastante interessante... Eu havia notado um comportamento estranho no Apache: eu tinha um script PHP que necessitava de uma enormidade de memória (coisa de 200MB). Usando o gnome-system-monitor, vi o uso de memória do sistema crescer para mais de 400MB enquanto o programa executava (só o Apache, e portanto meu programa PHP, usava em torno de 300MB). Depois que o programa terminou, esses 300MB não foram liberados pelo sistema. Trem doido, sô!
Bastante interessante... Eu havia notado um comportamento estranho no Apache: eu tinha um script PHP que necessitava de uma enormidade de memória (coisa de 200MB). Usando o gnome-system-monitor, vi o uso de memória do sistema crescer para mais de 400MB enquanto o programa executava (só o Apache, e portanto meu programa PHP, usava em torno de 300MB). Depois que o programa terminou, esses 300MB não foram liberados pelo sistema. Trem doido, sô!
[2] Comentário enviado por bogdano em 03/07/2004 - 21:54h
Muito interessante o artigo. Agradeço por compartilhar o seu conhecimento
Muito interessante o artigo. Agradeço por compartilhar o seu conhecimento
[3] Comentário enviado por hilmilho em 02/12/2004 - 09:15h
Quanto aos 300MB que o espinafre falou se foi usada essa biblioteca mencionada no arquivo deveria ter liberado.
Quanto aos 300MB que o espinafre falou se foi usada essa biblioteca mencionada no arquivo deveria ter liberado.
[4] Comentário enviado por nick_skyp em 16/01/2005 - 04:47h
realmente mto interessante!!
parabeins.. ms pintou uma duvida aki...
a STD C é implementada em C, certo?
ela usa "lista circular" para guardar areas de memoria(livres ou naum), ateh aeh blza... ms jah qdo se fala em lista, eu soh consigo pensar em alocação dinâmica... :-) naum sei se eh assim q funciona na STD C, ms essa lista na verdade tem tamanho limitado? (estatica)...
se naum, como eh que funciona o processo de "criação dos nós dessa 'lista livre' ?? (dinamica), senão atraves do sistema operacional ou pelo uso de seus proprios nós?? "
humm.. fikou confuso agora :S...
realmente mto interessante!!
parabeins.. ms pintou uma duvida aki...
a STD C é implementada em C, certo?
ela usa "lista circular" para guardar areas de memoria(livres ou naum), ateh aeh blza... ms jah qdo se fala em lista, eu soh consigo pensar em alocação dinâmica... :-) naum sei se eh assim q funciona na STD C, ms essa lista na verdade tem tamanho limitado? (estatica)...
se naum, como eh que funciona o processo de "criação dos nós dessa 'lista livre' ?? (dinamica), senão atraves do sistema operacional ou pelo uso de seus proprios nós?? "
humm.. fikou confuso agora :S...
[5] Comentário enviado por ron_lima em 16/01/2005 - 08:50h
A lista livre nada mais é que uma lista encadeada. Sempre que as funções calloc, malloc ou realloc solicitam mais memória do sistema operacional, esta nova arena de memória é ligada à esta lista. Esta lista não tem limite e a quantidade de memória a ser alocada é limitada pelo sistema operacional.
Quando seu programa chama a função "free", na verdade a arena de memória passada como parâmetro volta à lista encadeada, onde é marcada como "disponível para realocação". Este comportamento tem uma vantagem em termos de performance, pois qualquer realocação de memória subseqüente não será realizada através de chamadas de sistema.
No caso do que o espinafre disse, o efeito é este mesmo: seu programa jamais vai liberar memória de volta para o sistema operacional. Por exemplo, se o seu programa tem um core de tamanho 10k e aloca mais 10k, ele ficará, durante toda sua execução, ocupando 20k de memória, mesmo que você chame a função free exaustivamente. Como dito no artigo, a função free não libera memória para o sistema operacional, mas a disponibiliza em uma lista encadeada interna à biblioteca STDC para realocação futura.
Como boa literatura sobre o assunto, um excelente livro é o do Kernighan e Ritchie - Linguagem C, onde apresentam um alocador de memória simples. Outro excelente livro é A Biblioteca Standard C, de P.J. Plauger que participou do X3J11.
A lista livre nada mais é que uma lista encadeada. Sempre que as funções calloc, malloc ou realloc solicitam mais memória do sistema operacional, esta nova arena de memória é ligada à esta lista. Esta lista não tem limite e a quantidade de memória a ser alocada é limitada pelo sistema operacional.
Quando seu programa chama a função "free", na verdade a arena de memória passada como parâmetro volta à lista encadeada, onde é marcada como "disponível para realocação". Este comportamento tem uma vantagem em termos de performance, pois qualquer realocação de memória subseqüente não será realizada através de chamadas de sistema.
No caso do que o espinafre disse, o efeito é este mesmo: seu programa jamais vai liberar memória de volta para o sistema operacional. Por exemplo, se o seu programa tem um core de tamanho 10k e aloca mais 10k, ele ficará, durante toda sua execução, ocupando 20k de memória, mesmo que você chame a função free exaustivamente. Como dito no artigo, a função free não libera memória para o sistema operacional, mas a disponibiliza em uma lista encadeada interna à biblioteca STDC para realocação futura.
Como boa literatura sobre o assunto, um excelente livro é o do Kernighan e Ritchie - Linguagem C, onde apresentam um alocador de memória simples. Outro excelente livro é A Biblioteca Standard C, de P.J. Plauger que participou do X3J11.
[6] Comentário enviado por ron_lima em 16/01/2005 - 08:52h
Detalhando um pouco mais a lista... Quando a memória é solicitada ao sistema operacional, a biblioteca STDC aloca, na verdade, um pouquinho mais. Este "pouquinho" é para conter os pointers que serão usados para a ligação na lista livre.
Detalhando um pouco mais a lista... Quando a memória é solicitada ao sistema operacional, a biblioteca STDC aloca, na verdade, um pouquinho mais. Este "pouquinho" é para conter os pointers que serão usados para a ligação na lista livre.
[7] Comentário enviado por ron_lima em 16/01/2005 - 08:55h
Hilmilho, no caso do programa em PHP, realmente a memória não será liberada. O que ocorre é que o apache trabalha carregando módulos em seu espaço de endereçamento. Assim, o engine PHP será carregado dentro do espaço de endereçamento do apache. O que quer que o PHP aloque de memória ficará preso dentro do apache.
Existe uma forma de configurar isso, acredito eu, que é tornar o apache um servidor multi-processo. Assim, todas as solicitações que chegarem serão processadas por um processo filho que liberará tudo o que for alocado quando terminar.
Esta configuração torna o apache muito pesado pois é mais suave para o SO criar uma thread do que um processo inteiro. Sem falar que a criação de um processo inteiro provoca a duplicação de todo o address space do processo pai, o que é um senhor overhead.
Hilmilho, no caso do programa em PHP, realmente a memória não será liberada. O que ocorre é que o apache trabalha carregando módulos em seu espaço de endereçamento. Assim, o engine PHP será carregado dentro do espaço de endereçamento do apache. O que quer que o PHP aloque de memória ficará preso dentro do apache.
Existe uma forma de configurar isso, acredito eu, que é tornar o apache um servidor multi-processo. Assim, todas as solicitações que chegarem serão processadas por um processo filho que liberará tudo o que for alocado quando terminar.
Esta configuração torna o apache muito pesado pois é mais suave para o SO criar uma thread do que um processo inteiro. Sem falar que a criação de um processo inteiro provoca a duplicação de todo o address space do processo pai, o que é um senhor overhead.
[8] Comentário enviado por nick_skyp em 16/01/2005 - 17:14h
humm.. valeu explicou melhor.. qestao da lista agora...
na verdade em um caso bem particular.. esse "poukinho alocado a mais pelo STD C" pode resultar por exemplo em um MALLOC retornando NULL... certo!?? ^^
humm.. valeu explicou melhor.. qestao da lista agora...
na verdade em um caso bem particular.. esse "poukinho alocado a mais pelo STD C" pode resultar por exemplo em um MALLOC retornando NULL... certo!?? ^^
[9] Comentário enviado por ron_lima em 16/01/2005 - 22:00h
Não. Este pouquinho a mais usualmente não ultrapassa mais que 4 bytes, dependendo da plataforma (em plataformas de 64 bits, este valor chega a 8 bytes). Se bem que isso depende, muito, da implementação da libC que você esteja usando. Esta é uma estimativa. A implementação do lib STDC é extremamente dependente do sistema operacional. As interfaces são sempre as mesmas, mas a implementação difere consideravelmente .Por exemplo, chamadas de sistema em uma máquina linux são completamente diferentes das chamadas de sistema em uma máquina Solaris.
A família de alocação de memória do STDC (malloc, calloc e realloc) podem retornar um ponteiro nulo apenas quando não há mais como obter memória para retornar ao programa. Isso acontece da seguinte maneira: Seu programa requisita memória à biblioteca STDC, seja chamando malloc, calloc ou realloc. Estas funções, em um primeiro momento, irão tentar localizar uma arena de memória com o tamanho solicitado na lista livre. Caso não exista, estas funções vão solicitar memória ao sistema operacional. Porém, se o processo chegou a um determinado limite, seja por imposição do administrador do sistema em alguns sistemas, seja por que realmente não existe mais memória disponível para alocação, a chamada de sistema irá falhar. Esta falha é traduzida pelas funções como um ponteiro inválido, cujo valor é zero (a macro NULL expande para a constante 0, que pode ser long dependendo do sistema).
O que se precisa ter em mente é que a idéia dos alocadores de memória do STDC é isolar seu programa da interface do sistema operacional, tornando, assim, seu programa independente de plataforma. Se você programar para unix usando o STDC, é garantido que seu programa funciona em Windows, Windows CE, Palm OS, BeOS e por aí vai.
Não. Este pouquinho a mais usualmente não ultrapassa mais que 4 bytes, dependendo da plataforma (em plataformas de 64 bits, este valor chega a 8 bytes). Se bem que isso depende, muito, da implementação da libC que você esteja usando. Esta é uma estimativa. A implementação do lib STDC é extremamente dependente do sistema operacional. As interfaces são sempre as mesmas, mas a implementação difere consideravelmente .Por exemplo, chamadas de sistema em uma máquina linux são completamente diferentes das chamadas de sistema em uma máquina Solaris.
A família de alocação de memória do STDC (malloc, calloc e realloc) podem retornar um ponteiro nulo apenas quando não há mais como obter memória para retornar ao programa. Isso acontece da seguinte maneira: Seu programa requisita memória à biblioteca STDC, seja chamando malloc, calloc ou realloc. Estas funções, em um primeiro momento, irão tentar localizar uma arena de memória com o tamanho solicitado na lista livre. Caso não exista, estas funções vão solicitar memória ao sistema operacional. Porém, se o processo chegou a um determinado limite, seja por imposição do administrador do sistema em alguns sistemas, seja por que realmente não existe mais memória disponível para alocação, a chamada de sistema irá falhar. Esta falha é traduzida pelas funções como um ponteiro inválido, cujo valor é zero (a macro NULL expande para a constante 0, que pode ser long dependendo do sistema).
O que se precisa ter em mente é que a idéia dos alocadores de memória do STDC é isolar seu programa da interface do sistema operacional, tornando, assim, seu programa independente de plataforma. Se você programar para unix usando o STDC, é garantido que seu programa funciona em Windows, Windows CE, Palm OS, BeOS e por aí vai.
[10] Comentário enviado por nick_skyp em 17/01/2005 - 04:48h
certo... valeu pelos esclarecimentos... ms qeria q c respondesse(se puder)... a pergunta q fiz no artigo de "introdução as bibliotecas em C"..
ateh logo e parabeins pelos artigos!
certo... valeu pelos esclarecimentos... ms qeria q c respondesse(se puder)... a pergunta q fiz no artigo de "introdução as bibliotecas em C"..
ateh logo e parabeins pelos artigos!
[12] Comentário enviado por f_Candido em 05/01/2008 - 00:34h
Muito bem abordado. Parabéns. Pensava de forma diferente. Valeu.
Muito bem abordado. Parabéns. Pensava de forma diferente. Valeu.
[13] Comentário enviado por ryonagana em 10/11/2008 - 12:38h
confesso que nao manjo muito de alocação dinâmica em C
pulei essa aula na facul e aprendi sozinho a fazer isso com C++ (usando new e delete)
uhauhahua agora que peguei o gosto nao consigo voltar pro C =(
confesso que nao manjo muito de alocação dinâmica em C
pulei essa aula na facul e aprendi sozinho a fazer isso com C++ (usando new e delete)
uhauhahua agora que peguei o gosto nao consigo voltar pro C =(
[14] Comentário enviado por ron_lima em 10/11/2008 - 18:44h
Os alocadores de memória do C++ funcionam exatamente da mesma maneira, ou seja, solicitam ao sistema operacional mais memória (caso do new) e devolvem a um pool interno no caso da desalocação (caso do delete). Da mesma maneira, o delete não devolve ao sistema operacional a memória alocada. A diferença básica é que estes operadores do C++ fazem um pouco mais do que apenas alocarem memória. No caso do new, ele também chama o construtor da sua classe e no caso do delete, o destrutor.
Os alocadores de memória do C++ funcionam exatamente da mesma maneira, ou seja, solicitam ao sistema operacional mais memória (caso do new) e devolvem a um pool interno no caso da desalocação (caso do delete). Da mesma maneira, o delete não devolve ao sistema operacional a memória alocada. A diferença básica é que estes operadores do C++ fazem um pouco mais do que apenas alocarem memória. No caso do new, ele também chama o construtor da sua classe e no caso do delete, o destrutor.
[15] Comentário enviado por ryonagana em 15/12/2008 - 18:21h
sim claro, é que eu confesso que nao sei usar malloc, calloc essas coisas
apesar de ser muito util, mas acho que esses comandos de C sao muito abaixo do nivel do c++
MAS se caso a pessoa quiser dar uma compatibilidade a mais, aconselho a usar esse modo
ou se a pessoa estiver programando um framework ,ou um sistema operacional e quiser fazer uma abstração de codigo
sim claro, é que eu confesso que nao sei usar malloc, calloc essas coisas
apesar de ser muito util, mas acho que esses comandos de C sao muito abaixo do nivel do c++
MAS se caso a pessoa quiser dar uma compatibilidade a mais, aconselho a usar esse modo
ou se a pessoa estiver programando um framework ,ou um sistema operacional e quiser fazer uma abstração de codigo
Patrocínio
Site hospedado pelo provedor RedeHost.
Destaques
Artigos
Enviar mensagem ao usuário trabalhando com as opções do php.ini
Meu Fork do Plugin de Integração do CVS para o KDevelop
Compartilhando a tela do Computador no Celular via Deskreen
Como Configurar um Túnel SSH Reverso para Acessar Sua Máquina Local a Partir de uma Máquina Remota
Configuração para desligamento automatizado de Computadores em um Ambiente Comercial
Dicas
Criando uma VPC na AWS via CLI
Multifuncional HP imprime mas não digitaliza
Dica básica para escrever um Artigo.
Como Exibir Imagens Aleatórias no Neofetch para Personalizar seu Terminal
Tópicos
Pegar a ultima ocorrencia viva (1)
Pq me aparece isso quando fui atualizar o Ubuntu 24.10 no terminal? (1)
como coloco para instalar com esse erro. (13)
Alguém sabe de documentos de texto e /ou vídeo aulas de certificações ... (1)
Top 10 do mês
-
Xerxes
1° lugar - 68.317 pts -
Fábio Berbert de Paula
2° lugar - 52.363 pts -
Buckminster
3° lugar - 19.433 pts -
Mauricio Ferrari
4° lugar - 16.172 pts -
Alberto Federman Neto.
5° lugar - 15.017 pts -
Daniel Lara Souza
6° lugar - 14.178 pts -
Diego Mendes Rodrigues
7° lugar - 13.826 pts -
edps
8° lugar - 11.760 pts -
Alessandro de Oliveira Faria (A.K.A. CABELO)
9° lugar - 11.212 pts -
Andre (pinduvoz)
10° lugar - 10.992 pts
Scripts
A maior comunidade GNU/Linux da América Latina! Artigos, dicas, tutoriais, fórum, scripts e muito mais. Ideal para quem busca auto-ajuda.
Site hospedado por:
