Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Entendendo e otimizando o Garbage Collection - Revista Java Magazine 103 - Parte 2
O artigo trata de apresentar o funcionamento dos collectors das JVMs Oracle JRockit (utilizada pelo servidor de aplicações Java EE WebLogic), IBM Virtual Machine for Java (utilizada pelo servidor de aplicações Java EE WebSphere
[fechar]
Você não gostou da qualidade deste conteúdo?
(opcional) Você gostaria de comentar o que não lhe agradou?
Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
[Artigo disponível no Leitor Digital DevMedia. Clique aqui para acessá-lo]
> Clique aqui para ler todos os artigos da Java Magazine 103
No artigo anterior da série “Entendendo e otimizando o Garbage Collection”, foram explicados fundamentos e detalhes sobre o processo de Garbage Collection em Java e o funcionamento dos collectors da JVM HotSpot 6 e 7. Além disso, foi apresentado como otimizar seu comportamento por meio de opções da JVM.
Apesar da maior parte dos desenvolvedores utilizar a JVM HotSpot, há outras JVMs no mercado que também sofrem dos mesmos problemas relacionados com Garbage Collection anteriormente apresentados. Estas JVMs apresentam diferentes interpretações para certos problemas, surgindo assim soluções criativas para cenários particulares.
A intenção deste artigo é dar continuidade a este estudo, agora abordando JVMs como Oracle JRockit (utilizada pelo servidor de aplicações Java EE WebLogic), IBM Virtual Machine for Java (utilizada pelo servidor de aplicações Java EE WebSphere), a especificação JSR-1 (também conhecida como Real-Time Specification for Java ou RTSJ) e finalmente a JVM Dalvik (utilizada por dispositivos Android).
Collectors da JVM JRockit (WebLogic)
A JVM Oracle JRockit, projetada especialmente para o servidor de aplicações Java EE WebLogic, é uma JVM comercial considerada de alta performance. Atualmente, ela está sendo integrada com a JVM HotSpot para o lançamento de uma nova JVM, possivelmente no JDK 8. Com relação a Garbage Collection, funciona de maneira um pouco diferente que a HotSpot.
Garbage collector dinâmico
A JVM JRockit possui um modo de Garbage Collection dinâmico, que combinará heurísticas e otimizará a performance de acordo com as necessidades da aplicação. A partir da definição do perfil do collector, a sua escolha acontecerá em tempo de execução, de forma parecida com Ergonomics da JVM HotSpot.
Este modo pode ser explicitamente escolhido utilizando a opção da JVM: -XgcPrio:, onde perfilDoCollector pode ser:
• throughput: otimização para maximização do throughput da aplicação;
• pausetime: otimização para a minimização do tempo de pausa;
• deterministic: otimização para tempos de pausa muito curtos e determinísticos.
Funcionamento geral
A JVM JRockit possui duas configurações possíveis da memória heap. A primeira delas é generacional, assim como na HotSpot, sendo dividida conforme a Figura 1, obtida do blog about:performance.
Aqui, a Young generation é chamada de Nursery, sendo subdividida em duas áreas: Keep Area, que não sofre collections e recebe os objetos após serem alocados; e a área remanescente, onde todos os seus objetos podem ser promovidos para Tenured, diferentemente dos espaços Survivor da HotSpot. JRockit promove um objeto para Tenured quando ele sobrevive a duas Minor collections. Por ser generacional, esta configuração busca fornecer tempo de pausa baixo.
Não há Permanent generation em JRockit. Todas as classes, strings e constantes são alocadas em Young ou Tenured generation. Por um lado, fica mais fácil de configurar e há mais memória para as outras generations; mas por outro lado, classes, strings e constantes podem ser coletadas quando não usadas novamente, o que pode introduzir problemas de performance.
"
Este é um post disponível para assinantes MVP
Apesar da maior parte dos desenvolvedores utilizar a JVM HotSpot, há outras JVMs no mercado que também sofrem dos mesmos problemas relacionados com Garbage Collection anteriormente apresentados. Estas JVMs apresentam diferentes interpretações para certos problemas, surgindo assim soluções criativas para cenários particulares.
A intenção deste artigo é dar continuidade a este estudo, agora abordando JVMs como Oracle JRockit (utilizada pelo servidor de aplicações Java EE WebLogic), IBM Virtual Machine for Java (utilizada pelo servidor de aplicações Java EE WebSphere), a especificação JSR-1 (também conhecida como Real-Time Specification for Java ou RTSJ) e finalmente a JVM Dalvik (utilizada por dispositivos Android).
Collectors da JVM JRockit (WebLogic)
A JVM Oracle JRockit, projetada especialmente para o servidor de aplicações Java EE WebLogic, é uma JVM comercial considerada de alta performance. Atualmente, ela está sendo integrada com a JVM HotSpot para o lançamento de uma nova JVM, possivelmente no JDK 8. Com relação a Garbage Collection, funciona de maneira um pouco diferente que a HotSpot.
Garbage collector dinâmico
A JVM JRockit possui um modo de Garbage Collection dinâmico, que combinará heurísticas e otimizará a performance de acordo com as necessidades da aplicação. A partir da definição do perfil do collector, a sua escolha acontecerá em tempo de execução, de forma parecida com Ergonomics da JVM HotSpot.
Este modo pode ser explicitamente escolhido utilizando a opção da JVM: -XgcPrio:, onde perfilDoCollector pode ser:
• throughput: otimização para maximização do throughput da aplicação;
• pausetime: otimização para a minimização do tempo de pausa;
• deterministic: otimização para tempos de pausa muito curtos e determinísticos.
Funcionamento geral
A JVM JRockit possui duas configurações possíveis da memória heap. A primeira delas é generacional, assim como na HotSpot, sendo dividida conforme a Figura 1, obtida do blog about:performance.
Aqui, a Young generation é chamada de Nursery, sendo subdividida em duas áreas: Keep Area, que não sofre collections e recebe os objetos após serem alocados; e a área remanescente, onde todos os seus objetos podem ser promovidos para Tenured, diferentemente dos espaços Survivor da HotSpot. JRockit promove um objeto para Tenured quando ele sobrevive a duas Minor collections. Por ser generacional, esta configuração busca fornecer tempo de pausa baixo.
Não há Permanent generation em JRockit. Todas as classes, strings e constantes são alocadas em Young ou Tenured generation. Por um lado, fica mais fácil de configurar e há mais memória para as outras generations; mas por outro lado, classes, strings e constantes podem ser coletadas quando não usadas novamente, o que pode introduzir problemas de performance.
"
A exibição deste artigo foi interrompida.
Este é um post disponível para assinantes MVPEste post também está disponível para assinantes da Java Magazine DIGITAL
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
ou para quem possui Créditos DevMedia. Clique aqui para saber mais!
Gerente de Engenharia, Líder Técnico e Desenvolvedor Java Web na Avenue Code. Graduado em Ciência da Computação na UNIFEI e especialista em Arquitetura de Sistemas Distribuídos na PUC Minas, é SCJP e SCWCD. Site: www.tgarcia.com.br
O que você achou deste post?
Cursos relacionados
Publicidade
