Artigo Java Magazine 60 - A memória do Java

As últimas novidades em GC e em ferramentas para a JVM

Conheça o novo coletor real-time Garbage-First, e aprenda a usar o VisualVM e VisualGC para diagnosticar o funcionamento da sua aplicação

De que se trata o artigo:

A Sun anunciou na JavaOne 2008 um novo algoritmo de GC – o “Garbage First” – que será disponível nos próximos releases do Java 7 e Java 6. Aproveitamos a deixa para explicar esse algoritmo e atualizar o leitor sobre gerenciamento de memória na JVM, apresentando outras novidades relacionadas, como as ferramentas VisualVM e VisualGC, também prestes a serem incluídas no JDK (a partir do Update 10). Finalmente, falamos um pouco do uso de Java para sistemas real-time.

A memória do Java:

Gerenciamento de memória é uma das tarefas mais críticas de qualquer aplicação. Na plataforma Java, o heap gerenciado com GC automática facilita muito a programação, mas o desempenho pode ainda ser uma preocupação, especialmente em aplicações que utilizam muita memória. O que é um caso cada vez mais comum, especialmente em aplicações Java EE escaláveis, trabalhando com heaps na ordem de gigabytes e atendendo a um número cada vez maior de transações simultâneas. É preciso conhecer um pouco da tecnologia de GC para fazer o tuning da JVM de forma a extrair o melhor desempenho possível. Existem várias referências detalhadas (citadas no artigo) sobre as opções de GC e seus parâmetros de configuração; mas também é importante conhecer ferramentas que permitem monitorar a JVM e observar seu comportamento, pois um bom tuning deve ser feito baseado em informações precisas.

Neste artigo, voltamos a um tema central na programação em Java ou em qualquer linguagem: gerenciamento de memória. Esta coluna já dedicou bastante espaço ao assunto, desde um panorama completo sobre GC em “Memória e Desempenho” na Edição 5 (hoje um item de colecionador), até atualizações como no artigo “Novas fronteiras na evolução do Java” (Edição 31). Mas a tecnologia de JVMs é um alvo em constante movimento devido ao aumento contínuo do escopo de aplicação da plataforma Java, que hoje se estende dos menores sistemas embutidos aos mais pesados servidores de aplicação. Já faz algum tempo que estou em dívida com o leitor, pois várias novidades têm surgido sobre o assunto.

Vamos, então, tirar o atraso e nos inteirarmos das últimas evoluções da tecnologia de gerenciamento de memória em Java. Examinaremos não só a teoria dos últimos algoritmos implementados por JVMs, mas também técnicas e ferramentas práticas, que auxiliam na otimização e suporte a aplicações Java – com ênfase no gerenciamento de memória, mas abordando também a monitoração geral da JVM e ainda estendendo um pouco o assunto de Java real-time.

Novos coletores no horizonte: A era real-time

Se eu fosse escrever uma história da tecnologia de GC, o livro teria três capítulos:

1)     A era stop the world (1960-2002): coletores que paralisam totalmente a aplicação, por períodos muitas vezes longos, enquanto limpam o heap;

2)     A era mostly concurrent (2003-2009): coletores “quase concorrentes” (que reduzem a um mínimo as pausas da aplicação), mas ainda sujeitos a pausas de duração e freqüência imprevisíveis;

3)     A era real-time (2010-): coletores cujas pausas são previsíveis, bem-comportadas, obedecendo a limites impostos pela aplicação.

As datas são escolhidas de acordo com a disponibilidade real de cada tecnologia (implementações maduras[1] e utilizadas em larga escala). A tecnologia de GC costuma ter um tempo de maturação bastante longo. Por exemplo, sobre GC real-time moderna, os primeiros papers de pesquisa datam de 1988, havendo estudos mais primitivos que levariam nesta direção desde 1978. Mas só agora, em 2008, esta tecnologia começa a estrear em plataformas de uso comercial – uma história de 20 anos! E eu creio que ainda demorará um par de anos até que a nova tecnologia se transforme no novo default, relegando as GCs mais antigas à categoria de legado.

Para o leitor curioso, é imperdível a apresentação “The Tortured History of Real-Time Garbage Collection” (http://www.cs.wustl.edu/~mdeters/doc/slides/rtgc-history.pdf), que mostra as muitas idas e vindas dessa dificílima pesquisa até 2003.

Pergunta: por que real time? Nos últimos anos, vimos uma adoção crescente do Java em aplicações com exigência soft real-time. Estas são aplicações que possuem requisitos temporais “importantes, mas não vida-ou-morte”. Como exemplo, podemos citar um sistema de call control, que precisa estabelecer dezenas ou centenas de ligações telefônicas por segundo, sendo que nenhuma ligação pode demorar mais que 500ms. Este é um requisito muito desejável, mas não crítico: se alguma ligação demorar até 2s devido a picos de full-GC, o resultado será apenas um pequeno aborrecimento para o usuário. Se isso ocorrer com freqüência suficientemente baixa, digamos menos de 1% das ligações, pode ser ignorado.

Outro exemplo importante é o de multimídia ou jogos animados: qualquer “travadinha” de uma pequena fração de segundo é suficiente para prejudicar a experiência do usuário, perdendo alguns frames. Mas ninguém deixará de jogar um game por causa de uma travada de meio segundo por hora. Até porque existem outras fontes de pequenas pausas indesejáveis, como leitura de dados de novos níveis a partir de CD, ...