BT
x Por favor preencha a pesquisa do InfoQ !

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.

Avalie esse artigo

Relevância
Estilo/Redação

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
Feedback geral
Bugs
Publicidade
Editorial
Marketing
InfoQ Brasil e todo o seu conteúdo: todos os direitos reservados. © 2006-2016 C4Media Inc.
Política de privacidade
BT

Percebemos que você está utilizando um bloqueador de propagandas

Nós entendemos porquê utilizar um bloqueador de propagandas. No entanto, nós precisamos da sua ajuda para manter o InfoQ gratuito. O InfoQ não compartilhará seus dados com nenhum terceiro sem que você autorize. Procuramos trabalhar com anúncios de empresas e produtos que sejam relevantes para nossos leitores. Por favor, considere adicionar o InfoQ como uma exceção no seu bloqueador de propagandas.