WinDBG: Memory II - Garbage Collector I

Neste primeiro post sobre GC, voc+� ir+� compreender seu objetivo e o conceito de gera+�+�es.

Enfim o t+�o esperado Garbage Collector. Apesar de n+�o ser um conceito novo, muitas pessoas desconhecem sua real fun+�+�o e estrutura. Na minha opini+�o, conhecer o Garbage Collector deveria ser tarefa b+�sica de todos desenvolvedor. Isso mesmo, desenvolvedor! Se o respons+�vel por alocar objetos n+�o conhece o funcionamento deste poderoso recurso, como poder+� ter certeza que est+� tratando a mem+�ria e os objetos da melhor maneira poss+�vel?

O que +� Garbage Collector?

A id+�ia de Garbage Collector n+�o +� nova, e muito menos pertence a uma determinada tecnologia. Em muitas conversas de Java x .NET (uma besteira imensa) j+� ouvi pessoas dizendo ".NET copiou o GC do Java".

O conceito de garbage collector (GC) nasceu em 1959 por John McCarthy, para resolver problemas do Lisp.
Seu objetivo principal +� fornecer um mecanismo autom+�tico para gerenciamento de mem+�ria, removendo objetos que n+�o ser+�o mais acessados na aplica+�+�o. A id+�ia +� deixar a responsabilidade de manter a mem+�ria consistente para um mecanismo autom+�tico.

Antigamente, esta responsabilidade era do desenvolvedor, que criava a objeto e removia-o da mem+�ria.
De cara podemos citar dois problemas:

1. O desenvolvedor poderia simplesmente "esquecer" de remover o objeto da mem+�ria; ou
2. poderia remover o objeto no momento errado, enquanto ainda havia ponteiros para ele.

Esta responsabilidade gerava uma esfor+�o muito grande, o que impactava diretamente no prazo, qualidade e testes de todos os projetos.

Conceito: Heap

O Heap +� um gerenciador de mem+�ria utilizado para alocar e liberar mem+�ria dinamicamente. Normalmente, a utiliza+�+�o do Heap +� realizada em situa+�+�es onde a quantidade de mem+�ria necess+�ria +� desconhecida, ou muito grande para ser armazenada no stack.

Mecanismo

Existem muitos algoritmos para um Garbage Collector hoje em dia, e todos s+�o dependentes do sistema operacional. Os GC trabalham intimamente com o Gerenciador de Mem+�ria do sistema. Por isso, +� importante saber que o GC do CLR n+�o +� igual ao GC da JVM.

Nestes posts iremos trabalhar apenas com o GC do CLR.

• Managed Heap

Toda aloca+�+�o e libera+�+�o de mem+�ria em uma aplica+�+�o .NET +� realizada atrav+�s do Garbage Collector. Por este motivo, o conceito de Managed Heap ser+� aplicado at+� o fim deste post. O GC gerencia todo o processo de ciclo de vida dos objetos, visando a melhor manuten+�+�o da aplica+�+�o e tentando evitar problemas de memory leaks, hangs ou crashes.

Quando um processo .NET +� iniciado, o sistema operacional aloca um espa+�o livre de mem+�ria, chamado de managed heap. Al+�m disso, o heap mantem um ponteiro de mem+�ria chamado NextObjPtr. Este ponteiro indica o local onde o pr+�ximo objeto deve ser alocado. A utiliza+�+�o deste ponteiro +� b+�sica: quando um novo objeto +� criado atrav+�s da instru+�+�o new, +� realizada a verifica+�+�o de espa+�o para sua aloca+�+�o. Se existe espa+�o suficiente, o objeto +� criado no endere+�o apontado pelo NextObjPtr, e este endere+�o +� retornado ao final do construtor.

Ao final deste processo, o NextObjPtr aponta para um novo endere+�o de mem+�ria dispon+�vel.

• Gera+�+�es

O Managed Heap +� dividido em gera+�+�es, Gen 0, Gen 1 e Gen 2, al+�m de uma +�rea para objetos grandes (acima de 85Kb). Cada gera+�+�o desta armazena objetos de "idades" diferentes, do mais novo (Gen 0) para o mais "antigo" (Gen 2). Mas antes, +� necess+�rio entender algumas suposi+�+�es importantes sobre o GC:

1. Quanto maior o objeto na mem+�ria, maior a probabilidade de ter uma vida mais longa. Essa suposi+�+�o assume que, quanto maior o objeto, mais trabalho existir+� para cri+�-lo, e programadores v+�o utiliz+�-lo quando necess+�rio e por mais tempo, como cache;
2. Quanto mais tempo um objeto permanece vivo, a probabilidade de exisitir mais tempo aumenta;
3. Todos os objetos s+�o inv+�lidos, at+� que provem que n+�o.

Por esse motivo as gera+�+�es s+�o utilizadas.

Quando o GC inicia um processo de limpeza, todos os objetos da gera+�+�o 0 que cont+�m alguma raiz s+�o enviados para a gera+�+�o 1, pois s+�o considerados vivos. Ap+�s este processo, a gera+�+�o 0 fica vazia.

Agora algumas quest+�es que voc+�s podem estar se perguntando:

Quando uma limpeza ocorre? Quando o GC ir+� executar?

O GC ir+� rodar quando uma nova aloca+�+�o precisa ser realizada e n+�o h+� espa+�o suficiente para isso na gen 0. Nesse caso, o GC executa a limpeza na gera+�+�o 0. Se aloca+�+�es por conta desta limpeza ocorrem na gera+�+�o 1 (pelo GC) e tamb+�m n+�o h+� espa+�o, uma limpeza na gera+�+�o 1 +� realizada, e o mesmo ocorre com a gera+�+�o 2.

IMPORTANTE: Objetos que permanecem vivos depois de uma limpeza sempre v+�o para a gera+�+�o seguinte.

LEMBRE-SE: O GC sempre ir+� limpar apenas a gera+�+�o 0, sem olhar para objetos com ou sem raiz nas gera+�+�o seguintes. Isso s+� ir+� ocorrer quando a limpeza da gera+�+�o 0 n+�o liberar espa+�o suficiente para uma nova aloca+�+�o.

Outra maneira do GC executar +� invocando o m+�todo GC.Collect(). Mas isso ser+� um quest+�o para depois. O importante +� n+�o utilizar isso, quase nunca!

--

Refer+�ncias:

http://msdn.microsoft.com/en-us/library/ms973837.aspx

http://msdn.microsoft.com/en-us/magazine/bb985010.aspx

http://blogs.msdn.com/tess/archive/2007/04/10/net-garbage-collector-popquiz-followup.aspx

http://grounding.co.za/blogs/brett/archive/2007/07/16/garbage-collection-basics.aspx

Livro Advanced Windows Debugging, de Mario Hewardt e Daniel Pravat;

--

O pr+�ximo post ir+� introduzir conceitos de execu+�+�o, finaliza+�+�o e dipose, para ent+�o partir para WinDBG em Memory Leaks.

Abra+�os!