Go 1.26: O Coletor de Lixo Green Tea e os Desafios na Otimização de Memória

A arquitetura do Go, desde suas raízes no tcmalloc, emprega um sistema de alocação de memória segregado por tamanho. Objetos de tamanhos similares são agrupados em blocos contíguos, chamados de spans, cada um com uma ou mais páginas de 8 KiB. Essa organização é pensada para otimização inicial, mas seu coletor de lixo, agora com o Green Tea, opera de uma forma que gerou novos desafios.

O Green Tea GC aprimora a cache-friendliness ao escanear spans de memória por objetos e ponteiros, enfileirando spans futuros para varredura. Isso reduz o acesso randômico à memória que caracterizava os coletores anteriores, onde o GC seguia cada ponteiro individualmente, causando mais cache misses. A otimização se manifesta em menores misses per kilo instructions (MPKI) na cache L1, resultando em programas mais rápidos, mesmo que a taxa de misses na L3 possa parecer maior. Contudo, o Green Tea não move objetos para compactar a memória, uma limitação que impede a recuperação de páginas esparsas, um ponto onde coletores móveis, como o do C#, mostram vantagem ao consolidar o uso de memória.

Quando o CEVIU News cobriu o lançamento do Go 1.25 em 17 de junho de 2026, destacamos melhorias na cadeia de ferramentas, runtime e biblioteca padrão. Embora o Green Tea GC tenha sido introduzido nessa versão anterior, não foi o foco principal daquele anúncio.

Agora, com o Go 1.26, o Green Tea não é apenas uma novidade, mas se tornou o coletor de lixo padrão. Essa mudança indica uma consolidação da tecnologia, trazendo à tona tanto seus benefícios de otimização de cache quanto seus desafios inerentes, como a dificuldade em recuperar memória de páginas esparsas devido à sua natureza não-moving.

A performance do coletor de lixo impacta diretamente a experiência do desenvolvedor e a eficiência de aplicações Go, especialmente em sistemas de alta concorrência e uso intensivo de memória. Entender como o Green Tea GC gerencia a memória, otimizando o uso da cache, é crucial para escrever código Go mais performático.

A limitação na recuperação de memória em páginas esparsas mostra um trade-off importante: ganhos em cache-friendliness versus a capacidade de compactação de memória. Para desenvolvedores, isso significa uma necessidade maior de projetar estruturas de dados e algoritmos que minimizem a fragmentação e evitem cenários onde a memória liberada não é de fato recuperada pelo sistema operacional, influenciando o consumo de recursos e a sustentabilidade de aplicações.