O Go 1.26 trouxe uma das maiores mudanças no runtime dos últimos anos: o Green Tea garbage collector agora vem habilitado por padrão. Neste post, vamos entender o que mudou, por que isso importa e o que esperar na prática.

O que é o Green Tea GC?

O Green Tea GC é uma reformulação do garbage collector do Go. Ele mantém a mesma abordagem mark-sweep do GC anterior, mas muda fundamentalmente a forma como os objetos são rastreados e escaneados.

A diferença principal: em vez de operar objeto por objeto espalhado pelo heap, o Green Tea trabalha no nível de páginas de memória. Ele agrupa objetos em blocos contíguos de 8 KiB chamados spans e escaneia vários objetos de uma vez dentro do mesmo span.

Como funciona na prática

O foco está em objetos pequenos — até 512 bytes — que são os mais comuns e os mais custosos para escanear individualmente.

Quando o GC encontra um objeto que precisa ser escaneado, ele não o faz imediatamente. Em vez disso, marca a posição do objeto dentro do seu span e espera até acumular vários objetos no mesmo span. Quando processa o span, escaneia todos de uma vez.

Esta abordagem melhora a localidade de cache de forma significativa: aceder a memória contígua é muito mais rápido do que saltar entre endereços espalhados pelo heap.

Distribuição de trabalho entre cores

O GC anterior usava uma fila global para distribuir trabalho entre goroutines. Isso criava contenção quando vários cores tentavam aceder à fila ao mesmo tempo.

O Green Tea resolve isso com filas locais por worker. Cada worker tem a sua própria fila de spans para processar. Quando um worker fica ocioso, ele “rouba” tarefas de outros workers — um padrão conhecido como work stealing. Isso elimina o gargalo central e escala melhor com mais cores.

Resultados de performance

Os números são animadores:

• 10% a 40% de redução no overhead do GC em programas reais com uso intensivo de coleta.

• ~10% adicional em plataformas AMD64 modernas, graças ao uso de instruções vetoriais (AVX-256 e AVX-512) para acelerar o escaneamento de objetos pequenos.

Isto não é um benchmark sintético — são ganhos observados em aplicações de produção.

O trade-off: mais memória residente

Nem tudo são flores. Benchmarks iniciais mostram um aumento de 8% a 15% no RSS (Resident Set Size). Este é o custo da estratégia de escaneamento por spans: manter mais metadados por página consome mais memória base.

Para a maioria das aplicações, este trade-off vale a pena. Mas se o seu caso exige o menor footprint de memória possível, vale monitorizar.

Como desabilitar

Se precisar de voltar ao GC anterior, basta compilar com: GOEXPERIMENT=nogreenteagc go build ./...

Mas a recomendação é testar com o Green Tea habilitado primeiro — os ganhos são reais para a maioria dos cenários.

Relação com outras otimizações do Go 1.26

O Green Tea GC complementa a alocação especulativa na stack que já estava disponível desde o Go 1.25. Enquanto a alocação na stack reduz a quantidade de objetos que chegam ao heap, o Green Tea melhora a eficiência de coleta dos objetos que inevitavelmente vão parar lá.

Combinadas, estas duas otimizações atacam o problema de performance do GC por dois ângulos: menos lixo para coletar e coleta mais rápida do lixo restante.

Conclusão

O Green Tea GC é o tipo de melhoria que demonstra a maturidade do runtime do Go. Sem mudar a API, sem quebrar a compatibilidade, a equipa do Go entregou ganhos significativos de performance que obtém simplesmente atualizando o toolchain.