DEV Community

Cristiano Rodrigues for Unhacked

Posted on

Allocation Budget, você sabe o que é?

É comum ouvirmos que não compreendemos exatamente como o GC é ativado. Neste artigo, buscaremos desmistificar esse assunto, explorando como o GC é acionado e gerencia as alocações.

Em linhas gerais, o GC é responsável por gerenciar as alocações de memória, então é natural que seja ativado com base nessas alocações. Nesse contexto, surge o conceito de Allocation Budget, que desempenha um papel importante no acionamento do GC.

Além do Allocation Budget existem outros fatores que podem desencadear a ativação do GC, como a alta pressão da memória física da máquina ou a chamada explícita do método GC.Collect() pelo usuário.

O Allocation Budget é um valor calculado por Geração do GC que ao ser alcançado/ultrapassado, pode "condenar" a geração a coleta.

Para Gen0 esse valor é verificado a cada nova alocação e para a Gen1 e Gen2 onde não existem objetos novos alocados direto nestas gerações então nestes casos serão utilizados os objetos promovidos.

O valor do Allocation Budget é calculado principalmente utilizando a taxa de sobrevivência da geração, onde maior a quantidade de objetos sobreviventes maior será o valor do Allocation Budget a ideia é não executar GCs prematuros. Mas se observarmos uma baixa taxa de sobrevivência teremos gerações com tamanhos pequenos.

A Gen0 é a que recebe a maioria das alocações e possui um valor de Allocation Budget extremamente dinâmico. No entanto, o processo de execução do GC é complexo e leva em consideração outros pontos antes de proceder com a coleta.

Resumidamente, o processo é o seguinte:

  1. Uma nova alocação é feita na Gen0 para objetos com tamanho inferior a 85.000 bytes.
  2. O GC é acionado na Gen0 e verifica o Allocation Budget das outras gerações para determinar se a geração deve ser condenada.
  3. O GC avalia se é possível executar o GC de forma concorrente e se a compactação deve ser realizada. Nesse momento, as informações de fragmentação são inseridas no contexto.
  4. Se a execução concorrente for possível, a marcação e a limpeza são realizadas, não vai ocorre a compactação.
  5. Se a execução concorrente não for possível, a marcação é feita e é avaliado se a compactação é necessária. Se for, ela é realizada, caso contrário, a limpeza é realizada.

O processo acima está bem simplificado, pois não leva em conta o LOH (Large Object Heap) e o POH (Pinned Object Heap). Falaremos sobre eles em breve.

Compreender como o GC é ativado é fundamental para o desenvolvimento de aplicações eficientes e escaláveis. Saber como o Allocation Budget é calculado e como os diferentes fatores podem afetar a ativação do GC pode ajudar os desenvolvedores a otimizar o desempenho de suas aplicações e evitar problemas relacionados a gerenciamento de memória. Com esse conhecimento, é possível tomar decisões mais acertadas sobre como alocar e desalocar memória, melhorando assim a eficiência e a estabilidade de suas aplicações.

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

Top comments (0)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Please leave a ❤️ or a friendly comment on this post if you found it helpful!

Okay