BT

Garbage First Collector da Sun Elimina Amplamente a Baixa Latência/Alto Consumo

por Charles Humble , traduzido por Ricardo Almeida em 24 Abr 2009 |

O Garbage Collector da Sun chamado Garbage First (referenciado de G1) é o novo garbage collector de baixa latência planejado para substituir CMS no Hotspot da JVM.  É um coletor estilo servidor, dirigido a máquinas multi-processamento com muita memória. Existem duas grandes diferenças entre CMS e G1. Primeiro que o G1 é um coletor com compactação. Compactação, um processo o qual a vida de objetos são movidas para espaços de memória livre no fim da pilha (heap) de modo que outros espaços tornam-se uma área contínua de memória livre, é importante em aplicações de execução longa porque é inevitável que a pilha irá se fragmentar no decorrer do tempo. G1 compacta suficientemente para evitar completamente o uso de listas livres de granularidade fina para alocação, o que simplifica consideravelmente partes do coletor e sobretudo elimina questões de potenciais fragmentações. Bem como a compactação, G1 oferece pausas de coleta mais previsíveis do que pode obter com o coletor CMS e permite usuários configurar as pausas do coletor. Essa determinística forte dá ao G1 algumas características de um coletor de Tempo Real (Real-Time) verdadeiro, porém não é fortemente Tempo Real, uma vez que fatores como agendamento do Sistema Operacional ainda significam que pausas não podem ser garantidas. Para o desenvolvedor entretanto consideravelmente mais fácil de usar do que produtos Java de Tempo Real desde que o código existente é capaz de ter performance melhorada sem necessitar de qualquer alteração em código. G1 usa algumas técnicas interessantes, baseadas na marcação global de informação e outras métricas, para priorizar regiões para coleta de acordo com a eficiência da Garbage Collector. Um artigo InfoQ anterior fornece mais detalhes técnicos.

Em um podcast recente,, James Gosling destacou a importância do G1 para certos tipos de aplicações Java de larga escala, semelhante a intercâmbios financeiros, que são caracterizados por grandes quantidades de dados vivos na pilha e considerável paralelismo no nível de thread, e são executados frequentemente em processadores multi-core:

"...o segredo profundo sobre muito dessas aplicações Java é que eles não usam banco de dados realmente. Ao invés de banco de dados eles usam muita RAM e empurram o garbage collector igual maluco porque eles não podem se dar ao luxo de tocar o disco sempre. Quando você está fazendo muitos, muitos milhares de transações por segundo, é bom manter tudo na RAM, usando tabelas hash, obtendo muitos núcleos focados nas transações na medida do possível, e geralmente ter grande questões sobre latência de operação.""

Gosling fala da diferênça entre consumo e determinismo. Tipicamente um garbage collector é otimizado para um ou outro. Um garbage collector otimizado para consumo é ideal para executar tarefas de segundo plano muito longas, onde pausas para garbage collector não são um problema para terminar a tarefa de segundo plano o mais rapidamente possível. Inversamente, se você está trabalhando em um sistema iterativo semelhante a uma aplicação web, então uma baixa latência do garbage collector é geralmente a melhor escolha. Gosling mostra o ponto que essas diferenças também existem em outras partes da JVM e que geralmente a JVM é otimizada para consumo. Realmente:

""Isso acontece todo lugar onde existe algoritmos que reorganizam algo. Então ter uma tabela hash - todos pensam que uma tabela hash tem tempo constante de inserção e tempo constante de remoção, o que é falso. O tempo de inserção é constante até ter que recolocá-lo no hash e depois uma insersão vai levar um bom tempo.""

Permitindo usuários especificar que o garbage collection não consuma mais que x ms de tempo, o G1 pode tentar manter pausas de collection como pequenos e não frequentes como for necessário para a aplicação, mas não tão lento como to diminuir consumo ou aumentar desnecessariamente a pegada. Dado que o garbage collector tem uma das áreas onde o ganho lento de latência é mais visível, o G1 deve oferecer benefícios significantes para desenvolvedores Java Enterprise. Está disponível no release do Java 6 update 14 e o time do Hotspot da Sun está extremamente vivo para ter feedback e bug reports dos que adotam cedo.

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Conteúdo educacional

Feedback geral
Bugs
Publicidade
Editorial
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2014 C4Media Inc.
Política de privacidade
BT