DEV Community

João Victor Martins
João Victor Martins

Posted on

2

[PT-BR] Mark and Sweep e as gerações da heap

Um dos objetivos da JVM é gerenciar a memória utilizada pelos nossos sistemas. Isto é feito através de processos que são executados ao longo do ciclo de vida da aplicação. O garbage collector é um dos mais importantes. De forma resumida, ele é o responsável por liberar espaço na memória, coletando objetos que não estão mais sendo referenciados. A ideia deste post é explicar, em detalhes, como é feita esta coleta.

Garbage Collector

Sempre que instanciamos um objeto na nossa aplicação, o mesmo é alocado em um espaço de memória chamado heap. Com o passar do tempo muitos objetos perdem suas referências e não são mais úteis para o sistema. Com um acumulo de objetos não referenciados, o garbage collector é invocado. O processo é chamado de mark and sweep e envolve dois passos. No primeiro passo é necessário descobrir quais objetos ainda possuem referência. Uma vez descobertos estes objetos serão marcados. No segundo passo, todos os outros objetos que não foram marcados estarão prontos para a coleta e é nesse momento que ocorre uma varredura para liberação do espaço de memória. Um detalhe que não foi informado é que enquanto o processo é executado, a aplicação para de rodar, com o intuito de evitar concorrência com o garbage collector. Essa parada é chamada de stop the world. Se sempre que o garbage collector for varrer a heap, os objetos que possuem referência forem marcados, elevará o tempo da parada e os usuários sentirão que a aplicação não está respondendo naquele momento, o que não é interessante. Então como fazer para melhorar o processo de coleta?

Young e Old Generation

Para evitar o problema visto anteriormente, a heap foi dividida em gerações. Essas gerações são a young generation e a old generation. A young possui um espaço menor e é dividida em 3 partes, que são o eden, s0 e s1 (survivor espaces). Todo novo objeto será criado no eden. Conforme aumenta a quantidade de objetos no eden, o garbage collector é chamado, porém o processo de marcação e varredura leva menos tempo, pois conforme informado, há menos espaço destinado para a young generation. Após a execução do gc, os objetos que ainda possuem referência, serão alocados no espaço s0. Como novos objetos estão sendo criados no eden, quando o gc é executado, ele irá olhar para os sobreviventes do eden e do s0 e os migrará para o espaço s1. Após esse processo inicial, todos os objetos criados no eden, poderão ser migrados para o s0 ou s1, sem ordem de precedência e o gc atuará em todos estes espaços. Após um número x de execuções (a depender da JVM e configurações feitas pelos usuários) os objetos sobreviventes na young generation, serão fragmentados e movidos para a old generation. Na old generation o processo de coleta será executado apenas quando necessário, ou seja, quando não possuir mais espaço e isso ocorrerá com menor frequência.

Conclusão

Percebemos que o garbage collector é um processo extremamente importante para mantermos a performance da nossa aplicação. Porém, se fosse realizado a coleta em toda a heap, por existir o stop the world, a aplicação pararia de executar, para não concorrer com o gc e isso causaria uma instisfação aos usuários do sistema, que iriam sentir que a aplicação não estaria respondendo naquele momento. Isso é evitado graças as gerações da heap. Na young generation o processo de coleta é executado com maior frequência, mas de forma muito rápida, pois é um espaço menor, fazendo com que não seja percebida pelos usuários. Já na old generation, espaço que possui os objetos sobreviventes, o processo é executado apenas quando necessário, com uma frequência bem menor, e quando ocorre, apesar de ser sentido pelos usuários, não é tão prejudicial. O assunto do post de hoje foi curto, porém complexo, então toda crítica, dúvida ou sugestão serão bem-vindas. Espero que tenham gostado. Até o próximo.

Image of Timescale

🚀 pgai Vectorizer: SQLAlchemy and LiteLLM Make Vector Search Simple

We built pgai Vectorizer to simplify embedding management for AI applications—without needing a separate database or complex infrastructure. Since launch, developers have created over 3,000 vectorizers on Timescale Cloud, with many more self-hosted.

Read more

Top comments (4)

Collapse
 
dearrudam profile image
Maximillian Arruda

Sempre aprendendo com seus posts mano!!! Valeu mesmo!!!

Collapse
 
j_a_o_v_c_t_r profile image
João Victor Martins

Eu que agradeço, Max!! Você é fera!! =)

Collapse
 
eduardoklosowski profile image
Eduardo Klosowski

Interessante, e é sempre bom saber como funciona os mecanismos internos, o que permite melhor otimizações e turning da configuração da JVM.

Collapse
 
j_a_o_v_c_t_r profile image
João Victor Martins

Que bom que gostou, Eduardo =)

Image of Docusign

🛠️ Bring your solution into Docusign. Reach over 1.6M customers.

Docusign is now extensible. Overcome challenges with disconnected products and inaccessible data by bringing your solutions into Docusign and publishing to 1.6M customers in the App Center.

Learn more