Java

Tpicosselecionados

deprogramao

em Gerncia de Memria em Java

Parte II: Monitorao e configurao da mquina

virtual HotSpot

Helder da RochaSetembro 2005

Otimizao da JVM HotSpot A HotSpot JVM permite a configurao de vrios

aspectos relacionados gerncia de memria Escolha de JVMs pr-configuradas (servidor e cliente) Ajustes absolutos e relativos do tamanho total e forma de

distribuio do espao do heap Ajuste de tamanho da pilha (para todos os threads) Escolha de diferentes algoritmos e estratgias de coleta de lixo Metas para auto-ajuste (ergonomics) visando performance

(throughput e baixas pausas) Tratamento de referncias fracas (soft references)

Esta apresentao explora esses recursos e aponta estratgias de ajuste visando melhor performance

2

Assuntos abordados

Tpicos1. HotSpot JVM: arquitetura de memria2. Parmetros de configurao de memria3. Escolha do coletor de lixo4. Monitorao de aplicaes5. Ajuste automtico (Java 5.0 Ergonomics)6. Apndice: class data sharing

3

Opes XX da JVM HotSpot Vrios parmetros de configurao mostrados nesta apresentao

usam opes XX do interpretador Javajava -XX:+Opo1 -XX:Opo2=5 ... [+opes] pacote.Classe

As opes -X e XX no so padronizados No fazem parte da especificao da JVM; podem mudar. Diferem entre algumas implementaes do HotSpot (ex: IBM)

H dois tipos de opes XX Valor booleano -XX: Valor inteiro -XX:=

Nas opes booleanas, o +/- serve para ligar/desligar uma opo-XX:+Opcao (liga uma opo que estava desligada por default)-XX:-Opcao (desliga uma opo que estava ligada por default)

Opes inteiras recebem o valor diretamente-XX:Valor=8

4

1. Arquitetura da HotSpot JVM

5

A mquina virtual configurada para as situaes mais comuns da plataforma usada

H duas opes bsicas a escolher Java HotSpot Client VM: minimiza tempo de incio da aplicao

e memria utilizada. Para iniciar a VM com esta opo, use: java client

Java HotSpot Server VM (opcional): maximiza velocidade de execuo da aplicao. Para iniciar a VM com esta opo, use java server

Tamanhos default do heap e geraes permanentes diferem nas duas opes

O tipo de mquina virtual usada pode ser selecionada automaticamente, de acordo com a plataforma Recurso do Java 5.0: JVM ergonomics: mquinas grandes

multiprocessadas usam Server VM e demais usam Client VM

Todas as VM HotSpot possuem

Compilador adaptativo Aplicaes so iniciadas usando o interpretador Ao longo do processo o cdigo analisado para localizar

gargalos de performance; trechos ineficientes so compilados e outras otimizaes (ex: inlining) so realizadas

Server VM (opo server) faz otimizaes mais agressivas

Alocao rpida de memria Liberao de memria automtica

Destruio automtica de objetos usando algoritmos eficientes de coleta de lixo adaptados ao ambiente usado

Default coletor serial em client e coletor paralelo de alta eficincia (throughput) em server

Sincronizao de threads escalvel

6

Coleta de lixo em Java: breve histria At a verso 1.1: nico coletor mark-and-sweep

Causa fragmentao de memria Alto custo de alocao e liberao (o heap inteiro precisava ser

varrido em cada coleta): pausas longas, throughput baixo

HotSpot (Java 1.2 e posterior): generational collector Gerao jovem: algortmo de cpia (garante que o espao livre

no heap seja sempre contguo: alocao eficiente) Gerao antiga: algoritmo Mark-Compact (sem fragmentao)

Java 1.3 a 1.5: vrias implementaes Diversas diferentes implementaes de algoritmos baseados em

geraes (serial, throughput, paralelo, concorrente, incremental) 1.5: auto-ajuste, escolha e otimizao baseado em ergonmica

Java 1.6 (Mustang) e Java 1.7 (Dolphin): ?7

Coletor de lixo serial Default na HotSpot Client VM Heap dividido em geraes (generational GC)

Heap total contm gerao jovem (trs reas) e gerao estvel(geralmente maior)

Gerao permanente (sem coleta ou coletada raramente) alocada parte do heap total

Algoritmos de coleta de lixo usados Gerao jovem: algoritmo de cpia com duas origens e dois

destinos (um temporrio e um permanente): coletas pequenas e freqentes: minor collection

Gero estvel (velha): algoritmo mark-compact: coletas maiores (totais) e raras: major collection

Gerao permanente: mark-sweep-compact: coleta muito rara

8

HotSpot: arquitetura do heap

virtual

virtual

virtual

Heap totalmximo-Xmx

Heapmnimo-Xms

Gerao jovem (young generation)

Gerao estvel (velha) (tenured generation)

Gerao permanente (permanent generation)

+

-XX:PermSize*

Coletas menores (freqentes)

Coletas maiores (infreqentes)

Coletas raras ou ausentes-XX:MaxPermSize

9* opes X e XX: da JVM (da Sun) no so padronizadas e podem mudar no futuro

Gerao jovem Usa algoritmo de cpia (coleta menor)

Objetos so criados no den (sempre origem) Sobreviventes so copiados para reas menores

10

virtual

den

Sobreviventes trocam de funo a

cada coleta

Sobreviventes(survivors)

Um dos sobreviventes (destino) est sempre vazio a qualquer momento

Origem (From)

Destino (To)

Coleta menor

Minor collection (Partial GC) Freqentes e rpidas

Acontecem sempre que o Eden enche Usam algoritmo de cpia (copying algorithm)

com duas reas de origem (from_space) e duas reas de destino (to_space) reas sobreviventes alternam funo de origem e

destino (uma sempre est vazia) rea Eden sempre origem; Gerao estvel sempre destino

11

Coletas menores: algoritmo Quando o GC executa uma coleta menor

Copia todos os objetos alcanveis do den e sobrevivente origem para a rea sobrevivente destino e/ou gerao estvel

Se objeto no couber no sobrevivente, vai para gerao estvel O GC pode promover um objeto que j foi copiado vrias vezes

entre as regies sobreviventes e torn-lo estvel

No final da coleta, den e rea sobrevivente origemesto vazios Origem muda de funo e passa a ser destino

Coletas seguintes copiam objetos entre sobreviventes ou para a gerao estvel (quando tiverem idade) Um objeto nunca volta ao den Objetos na gerao estvel nunca voltam gerao jovem

12

Coletas menores: exemplo Quando o den enche, GC copia objetos alcanveis

Do den (E) para sobrevivente To (St) sempre esvazia o den Do sobrevivente From (Sf) para St sempre esvazia o Sf De Sf para a gerao estvel (T) (dependente de algoritmo) Do den ou Sf para T (se no cabe em St)

E (Eden) Sf St T (Tenured)

E (Eden) St Sf T (Tenured)

13

Depois de1a. coleta

Depois de2a. coleta

Incio:Eden cheio

Eden cheionovamente

GC

GC

Objeto inalcanvel

A dana das referncias1. Dois objetos so criados no Eden e

inicializam as referncias a e b com endereos do Eden

ba

IncioEden ST Tenured Gen.SF

14

ba

2. Os objetos sobrevivem primeira coleta e socopiados para uma das duas regies de sobreviventes; as referncias a e b apontam paraos objetos nos novos endereos

Primeira coleta

3. Os objetos sobrevivem a uma segunda coleta. O GC decide copiar o objeto maior para a geraoestvel, enquanto que o objeto menor copiadopara a outra regio sobrevivente

ba

Segunda coleta

Eden

Eden

ST Tenured Gen.SF

ST Tenured Gen.SF

Gerao velha (estvel) Consiste principalmente de objetos que

sobreviveram a vrias coletas menores Objetos copiados vrias vezes de um

sobrevivente para a outro Algoritmo de GC usado decide quando

promover um objeto Objetos jovens que recebem referncias de

objetos estveis podem ser emancipados

Um objeto muito grande que no cabe no na rea den criado diretamente na gerao estvel

Pode estar sujeita fragmentao Resultado do algoritmo de GC usado (varia

conforme o tipo de coletor de lixo escolhido)15

Pilha

Gerao estvel

Gerao jovem

Coleta maior (completa) Major collection (Full GC) Coletas menores gradualmente enchem a regio estvel

Quando a gerao estvel est cheia, o GC executa uma coleta maior envolvendo todos os objetos de todas as geraes

A coleta maior (completa) pode acontecer antes, se O algoritmo do coletor escolhido for incremental Uma coleta menor no for possvel devido falta de espao

(sobreviventes esto cheios e h mais objetos ativos no Edenque caberiam na regio estvel)

Usa algoritmo mark-sweep (MS) ou mark-compact (MC) Depende do GC escolhido (concorrente, serial, paralelo, etc.) Demora bem mais que uma coleta menor, porm menos

freqente e pode nunca acontecer

16

Gerao permanente

17

Consiste de memria alocada por processos no-relacionados criao de objetos Carga de classes (ClassLoader) rea de mtodos (cdigo compilado) Classes geradas dinamicamente (ex: JSP) Objetos nativos (JNI)

Coletas de lixo so muito raras Usa algoritmo Mark-Sweep (com compactao quando cheio) Pode-se desligar a coleta de lixo nesta gerao: -Xnoclassgc Em MacOS X, existem uma gerao imortal: parte da gerao

permanente compartilhada e no afetada por coleta de lixo

No faz parte do heap total controlado pelas opes Xmx e Xms da mquina virtual Usa opes prprias XX:MaxPermSize

3. Configurao de memria H vrias opes para configurar o tamanho das

geraes, do heap total e da geropermanente Tambm possvel determinar o tamanho das pilhas

de cada thread Os ajustes pode ser realizados

De forma absoluta, com valores em bytes De forma relativa, com percentagens ou relaes de

proporcionalidade 1:n De forma automtica (usando ergonmica) baseada

em metas de performance

18

Tamanho absoluto do heap total

19

Heap total = gerao jovem + gerao estvel No inclui gerao permanente (configurada parte)-Xmx[k|m|g] Tamanho mximo do heap total Default*: -client: 64MB; -server: memria fsica ou 1GB)-Xms[k|m|g] Tamanho mnimo do heap total Default*: -client: 4MB; -server: 1/64 memria fsica ou 1GB)

Exemplos de usojava -Xmx256m -Xms128m ... heap ocupar espao entre 128 e 256 megabytes. java -Xmx256m -Xms256m ... heap ocupar exatamente 256 megabytes (tamanho fixo). Evita

que a JVM tenha que calcular se deve ou no aumentar o heap.* No dependa dos defaults: costumam variar entre plataformas, verses, fabricantes

Tamanho da gerao permanente A gerao permanente (onde classes compiladas so guardadas)

no faz parte do heap total Pode ser necessrio aument-la em situaes em que h uso de

reflexo e gerao de classes (ex: aplicaes EJB e JSP)

-XX:PermSize=[k,m,g] Define o tamanho inicial da gerao permanente

-XX:MaxPermSize=[k,m,g] Define o tamanho mximo da gerao permanente. Caso o sistema precise de mais espao que o permitido nesta opo,

causar OutOfMemoryError. Exemplos

java -XXPermSize=32m -XX:MaxPermSize=64m ... Aloca inicialmente 32 megabytes para a gerao permanente,

expansvel at 64 megabytes

20

Gerao jovem: tamanho absoluto Gerao jovem menor causa coletas pequenas mais freqentes Gerao jovem maior mais eficiente pois coletas sero mais raras

Mas se ocorrerem iro demorar mais, alm de reduzirem o espao para a gerao velha (o que pode causar coletas demoradas freqentes)

Para alterar o tamanho da gerao jovem, use as opes-XX:NewSize=[k,m,g] Define o tamanho mnimo da gerao jovem

-XX:MaxNewSize=[k,m,g] Define o tamanho mximo da gerao jovem

Exemplos de usojava -XX:NewSize=64m -XX:NewSize=64m ... Define um tamanho fixo de 64 megabytes para a gerao jovemjava -XX:NewSize=64m -XX:NewSize=64m ... Define mnimo de 64 MB e mximo de 128MB para a gerao jovem

21

Tamanho da pilha de cada thread Cada thread tem uma pilha

A pilha dividida em quadros (frames) para cada mtodo cujos dados no so compartilhados

Uma pilha grande evita StackOverflowError, porm se a aplicao tiver muitos threads (ex: servidores) a memria total pode ser consumida de forma ineficiente levando a OutOfMemoryError. Reduza o tamanho da pilha, havendo muitos threads, e teste a

ocorrncia de erros StackOverflowError. O tamanho de cada pilha pode ser definido com a opo

-Xss=[k,m,g] Define o tamanho da pilha (de cada thread)

Exemplos de usojava -Xss128k ... Altera o tamanho da pilha de cada thread para 128 quilobytes

22

-XX:NewSize

diferena max-min

diferena max-min

diferena max-min

Resumo:ajustes de memria

Valores de ajuste

absolutos

Heap: geraojovem

Heap: geraoestvel

Heap: geraopermanente

Tamanhomnimo

do heap-Xms +

-XX:MaxNewSize

Tamanho doheap total mximo

-Xmx

-XX:PermSize

-XX:MaxPermSize

23

Tamanho da pilha reservada

para cada thread-Xss

...Pilha

Tamanho relativo do heap real

24

Esses parmetros influenciam a JVM a aumentar ou diminuir o heap dentro da faixa -Xms/-Xmx Se Xms for igual a Xmx eles no sero considerados-XX:MinHeapFreeRatio= Define a percentagem mnima do heap que precisa estar

disponvel aps uma coleta. Default* = 40% (Client JVM) Se aps uma coleta o heap disponvel no corresponder a no

mnimo esse valor, a JVM aumentar o espao do heapproporcionalmente at alcanar a meta ou atingir o limite

-XX:MaxHeapFreeRatio= Define a percentagem mxima do heap que pode estar

disponvel aps uma coleta. Default* = 70% (Client JVM) Se aps uma coleta o heap disponvel for maior que este valor,

a JVM ir reduzir o espao do heap (reduz uso de memria) at alcanar a meta ou atingir o limite mnimo * valores default variam

entre plataformas/JVMs

Exemplo: crescimento do heapjava -Xms30m -Xmx100m

-XX:MinHeapFreeRatio=50-XX:MaxHeapFreeRatio=60 ...

25

utilizao do heapaumentou para 20MB

-Xmx: 100m(heap mximo)

-Xmx: 100m(heap mximo)

-Xms: 30MB (heap inicial)

33,3% free

66,7% used

Aumento do espao reservado ao heap

heap utilizado20MB

50% free

50% used

Exemplo: reduo do heapjava -Xms30m -Xmx100m

-XX:MinHeapFreeRatio=50-XX:MaxHeapFreeRatio=60 ...

-Xmx: 100m(heap mximo)

-Xmx: 100m(heap mximo)

26

Espao atualmente reservado ao heap

utilizao do heapcaiu para 20MB

75% free

25% used

Reduo do espao reservado ao heap

heap utilizado20MB

60% free

40% used

Conseqncias O ajuste do tamanho do heap o fator que tem o maior

impacto na performance da coleta de lixo geral Os valores atribudos ao heap inicial e heap mximo so valores

limite: a mquina virtual ir procurar utilizar a memria da forma mais eficiente, s ocupando o espao realmente necessrio

Aplicaes que variam o heap com freqncia podero melhorar a performance ajustando os parmetros de redimensionamento para refletir melhor o comportamento da aplicao

Pode-se definir -Xms and -Xmx para o mesmo valor, evitando o redimensionamento a cada coleta Aumenta a previsibilidade da aplicao Remove uma deciso da mquina virtual: no ser preciso

recalcular o uso do heap a cada coleta, mas a mquina virtual no poder compensar se escolha for mal feita.

27

Proporo gerao jovem/velha

28

-XX:NewRatio=n Define a proporo 1:n entre a gerao jovem e a gerao velha.

A gerao jovem ocupar 1/(n+1) do espao total do heap.

Valores default dependem do servidor usado No JVM Cliente* (opo -client) a relao 1:8 (NewRatio=8)

No JVM Servidor* (opo server) a relao 1:2 (NewRatio=2)

Exemplo de alteraojava -XX:NewRatio=3 ... n 3, ento a relao 1:3, ou seja, a gerao velha ser 4

vezes a gerao jovem. A gerao jovem ocupar 25% do heap.

Jovem EstvelHeap total

1/3 2/3

Jovem Estvel

1/9 8/9

Heap total

* caso tpico valores default variam entre plataformas

Garantia da gerao jovem Young Generation Guarantee [Sun 05] (YGG)

Reserva prvia de espao na gerao velha (estvel) No realizada em coletores paralelos

Para garantir uma coleta menor realizada com sucesso na hipteseem que todos os objetos estejam ativos, preciso reservar memria livre suficiente na gerao estvel para acomodar todos os objetos. O espao poder nunca ser usado: idealmente, os objetos sero

copiados do den e sobrevivente origem para o sobrevivente destino Mas no h garantia que todos os objetos cabero no sobrevivente.

O espao reservado pressupe o pior caso: igual ao tamanho do den mais os objetos no sobrevivente origem. No havendo como reservar o espao, ocorrer uma coleta completa.

Devido YGG, um den maior que metade do espao do heapcomprometido inutiliza as vantagens da Generational GC: apenas coletas maiores iriam ocorrer.

29

Conseqncias

30

Gerao jovem maior causa Menos coletas menores, porm com pausas maiores Gerao velha menor para um heap de tamanho limitado: aumentar a

freqncia de coletas maiores (mais lentas pausas maiores) Gerao jovem menor causa

Maior freqncia de coletas menores, de pausas curtas Gerao velha maior, o que pode adiar coletas maiores (que,

dependendo da aplicao, podem nunca ocorrer) Como escolher?

Analise a distribuio dos objetos alocados e estabilizados (tenured) durante a vida da aplicao. No ajuste se no for necessrio.

A menos que sejam detectados problemas com pausas longas ou muitas coletas maiores, aloque o mximo de memria gerao jovem

Veja se a garantia da gerao jovem (YGG) alcanada (no aumente alm da metade do espao usado do heap)

Alocao de objetos pode ocorrer em paralelo, ento aumente medida em que houver mais processadores.

Proporo den/sobreviventes

31

-XX:SurvivorRatio=n Proporo entre espaos sobreviventes e o den. O nmero

refere-se ao espao ocupado pelos dois espaos sobreviventes. Uma relao 1:n reserva 1/(n+2) do espao da gerao jovem

para cada sobrevivente

Default* n=25 (Client JVM; cada sobrevivente ocupa 1/27 do espao total da gerao jovem); n=30 (Server)

Exemplojava -Xmx=100m -XX:NewRatio=3 -XX:SurvivorRatio=3

127 25/27

gerao jovem

127

S1 denS2

3/5 1/5

den S1 S2 Estvel

1/5

1/4 3/475 MB mx25 MB mx

15 MB mx 5 MB mx (cada)

* valores default variam entre plataformas

Conseqncias Sobrevivente muito grande

Desperdcio de espao (um est sempre vazio) Coletas mais freqentes no den

Sobrevivente muito pequeno Enche muito rpido ou no cabe objetos, que so copiados diretamente

para a gerao velha Enche gerao velha mais rapidamente: +coletas maiores

A cada coleta, a JVM define o nmero de vezes (threshold) que um objeto pode ser copiado (entre sobreviventes) antes de ser promovido gerao estvel. O objetivo manter os sobreviventes cheios pela metade. Isto pode ser

modificado com -XX:TargetSurvivorRatio (default=50) A opo -XX:+PrintTenuringDistribution mostra esse valor e as idades

dos objetos na gerao estvel (velha). O valor mximo pode ser modificado com -XX:MaxTenuringThreshold

(default=31); se for zero objetos so promovidos na primeira coleta

32

3. Seleo do coletor de lixoH quatro coletores pr-configurados no J2SE 5.01. Serial collector (default em -client, SGC)

Ative com a opo -XX:+UseSerialGC2. Throughput collector (default em -server, TGC)

Ative com a opo -XX:+UseParallelGC3. Mostly-concurrent low pause collector (CMS)

Ative com a opo -XX:+UseConcMarkSweepGC4. Incremental (train) low pause collector (Train)

Ative com a opo -XX:+UseTrainGC Cada coletor usa uma combinao de algoritmos

disponveis otimizados para situaes distintas possvel configurar e combinar algoritmos diferentes

33

Algoritmos utilizados Algoritmos diferentes so usados para as diferentes

geraes e em plataformas multiprocessadas Gerao jovem

(1) Coletor serial (copying algorithm) - default(2) Coletor paralelo (concurrent copying algorithm)(3) Coletor paralelo de alta eficincia (scavenge)

Gerao estvel(4) Coletor mark-compact serial - default(5) Coletor mark-sweep concorrente (6) Coletor train incremental

Coletores pr-configurados combinam algoritmos e permitem ajustes e alteraes na configurao default

34

Coleta incremental (Train GC) Divide a velha gerao em vages (blocos de memria) e trens

(conjuntos de blocos) e realiza coletas de alguns blocos sempre que possvel, evitando parar a aplicao Mas no um algoritmo de tempo real, pois no possvel determinar

um limite mximo de pausas, nem saber quando ocorrem, nem h como impedir que todos os threads parem ao mesmo tempo

Impe alto custo sobre a performance: baixa eficincia (throughput) Para ativar use -XX:+UseTrainGC ou -Xincgc

Este coletor parou de ser atualizado na verso 1.4.2.

35

Gerao jovem

Gerao permanente

Gerao estvelusando train

algorithm

trens

vages

Coleta da gerao jovem Os algoritmos so todos de cpia Todos param o mundo A principal diferena ocorre em

sistemas multithreaded No coletor default, todos os threads so

interrompidos e um thread executa o algoritmo de cpia serial

Nos coletores paralelos, todos os threads so interrompidos e vrios threads executam um algoritmo de cpia concorrente

A pausa provocada em um coletor paralelo diminui com o aumento do nmero de processadores paralelos

Coletas menores (freqentes)

Pausa para

coleta

ColetorSerial

ColetorParalelo

36

Coleta da gerao estvel

37

Fragmentao Coletor serial mark-compact

compacta o espao Coletor concorrente mark-sweep

s compacta se espao acabar (alocao realizada durante coletas menores ser mais cara)

Quatro etapas do coletor concorrente1. Initial mark (stop-the-world,

um thread)2. Mark/pre-clean (paralelo, um thread)3. Remark (stop-the-world,

um ou mais threads)4. Sweep/reset (paralelo, um thread)

Coletas maiores (infreqentes)

Pausa

1. Initial mark

2. Mark &pre-clean

3. Remark

4. Sweep& reset

Mark-CompactSerial

Mark-SweepConcorrente

Coletores pr-configurados Serial (-XX:+UseSerialGC*): ideal para sistemas monoprocessados

Gerao jovem: coletor de cpia (1) (default) Gerao estvel: coletor mark-compact (4) (default)

Paralelo com eficincia mxima (-XX:+UseParallelGC) Gerao jovem: coletor de cpia concorrente de alta eficincia (3) Gerao estvel: default (4) (mark-compact serial)

Paralelo com pausas mnimas (-XX:+UseConcMarkSweepGC) Gerao jovem: default (1) (coletor de cpia serial);

verso concorrente (2) pode ser ligada com -XX:+UseParNewGC Gerao estvel: coletor mark-sweep concorrente (5) (com

compactao apenas quando memria cheia)

Incremental (-XX:+UseTrainGC) Gerao jovem: default (1) (cpia serial) ou -XX:+UseParNewGC (2) Gerao estvel: algoritmo train incremental (6)

38*Os parmetros XX:+Use*GC no devem ser combinados

Opes de paralelismo

39

-XX:+UseParNewGC Com esta opo a JVM usar um coletor de cpia paralelo (2)

para a gerao jovem. Esta opo s pode ser usada com os coletores que no

especificam um algoritmo para a gerao jovem: XX+:UseTrainGC ou XX:+UseConcMarkSweepGC

-XX:+CMSParallelRemarkEnabled Usada apenas no coletor CMS Com esta opo a remarcao (remark) feita em paralelo,

diminuindo as pausas. Requer o uso das opes -XX:+UseParNewGC e

-XX:+UseConcMarkSweepGC-XX:ParallelGCThreads=n (Default: no. threads disponveis)

Define o nmero de threads que sero usados pelo coletor paralelos da gerao jovem

Agendamento de coleta

40

Uma coleta concorrente deve iniciar e terminar antesque a gerao estvel fique cheia Difere do coletor serial que inicia quando a gerao enche

Para saber quando iniciar, o coletor mantm estatsticas para estimar o tempo que falta antes da gerao estvel encher e o tempo necessrio para realizar a coleta As suposies so conservadoras

Uma coleta concorrente tambm iniciar assim que a ocupao da gerao estvel passar de um certo limite Este valor pode ser alterado com a opo-XX:CMSInitiatingOccupancyFraction=nnonde nn a % do espao ocupado antes da coleta (0-100)

O valor inicial aproximadamente 68% do heap.

Modo incremental: CMS Vrias opes permitem diminuir pausas quando o CMS

for usado, atravs do modo incremental. As principais opes so:-XX:+CMSIncrementalMode (default: desabilitado) Habilita modo incremental-XX:+CMSIncrementalPacing (default: desabilitado) Permite ajuste automtico do ciclo com base em estatsticas

-XX:CMSIncrementalDutyCycle=n (default: 50) Percentagem de tempo (0-100) entre coletas menores em que o

coletor concorrente pode executar. Se pacing automtico habilitado, este o valor inicial.-XX:CMSIncrementalDutyCycleMin=n (default: 10) Percentagem (0-100) limite inferior do ciclo se pacing habilitado

Veja as vrias outras opes do CMS na documentao

41

TGC vs. CMS

42

TGC: Parallel Collector, a.k.a Throughput Collector Objetivo: mxima eficincia com eventuais pausas Aplicaes que usam esse coletor raramente realizam coletas

maiores; quando realizam, no tm problema se o sistema parar Importante que coletas menores sejam rpidas (so sempre

realizadas em paralelo) e eficincia a melhor possvel

CMS: Mostly-Concurrent Collector, a.k.a ConcurrentMark-Sweep (CMS) ou Low Latency Collector Objetivo: mnimo de pausas com eventual perda de eficincia Coletas maiores, apesar de pouco freqentes, podem impor

pausas muito longas (principalmente com heaps grandes) Este coletor diminui as pausas da coleta maior, fazendo rode em

paralelo com a aplicao principal (que fica mais lenta) Duas pequenas pausas da mesma ordem das coletas menores

(normalmente configuradas em paralelo tambm).

TGC vs. CMSHigh throughput vs. Low latency-XX:+UseParallelGC vs. -XX:+UseConcMarkSweepGC

com -XX:+UseParNewGC

Menos tempo total dedicado coletade lixo (eficiente)

Ocasional pausalonga (coleta na

gerao estvel serial e usa um

nico thread)

Alocao eficientenas duas geraessem fragmentao

100% GC

100% GC

33%* a 100% GC

Mais tempo total dedicado a GC(ineficiente)

Parcialmente incremental; pausas bem curtas

Pausas na nova gerao mais longas (alocao na gerao estvel mais cara devido fragmentaao)

100%GC

100%GC

100%GC

43* Neste exemplo, com 3 threads

Quando a escolha de um coletor de lixo importa para o usurio?

Para muitas aplicaes ele no faz diferena GC realiza pausas de pouca durao e freqncia.

Mas em sistemas grandes, pode ser significativo Compensa escolher o coletor de lixo correto e ajust-lo

Para maior parte das aplicaes o SerialGC adequado Os outros tm overhead e so mais complexos Se uma aplicao no precisa do comportamento especial de um

coletor alternativo, deve usar o coletor serial

Em grandes aplicaes com muitos threads, muita memria e muitos processadores, o coletor serial provavelmente no ser a melhor escolha Neste caso, a escolha inicial deve ser o ParallelGC (TGC)

44

Quando usar

45

SGC (SerialGC) Aplicao tpica, um processador, menos de 2GB de RAM

TGC (ParallelGC) Muitos threads alocando objetos (grande gerao jovem,

adiando ou evitando coleta estvel) Performance aumenta proporcionalmente ao nmero de

processadores paralelos Aplicao que tem que ser a mais eficiente possvel

CMS (ConcMarkSweepGC) Pode compartilhar recursos do processador com o coletor de

lixo enquanto a aplicao est executando Muitos dados de vida longa (grande gerao estvel) Requerimento de pausas mnimas (aplicaes interativas)

Train (TrainGC) Requerimento de pausas mnimas; aceita eficincia baixa

4. Monitorao de aplicaes Para ajustar os parmetros configurveis da mquina

virtual, preciso realizar medies Vrios parmetros da mquina virtual HotSpot fornecem

informaes teis Ferramentas grficas mostram o comportamento da mquina

virtual e sua alocao/liberao de memria

preciso saber O que ajustar e como ajustar O objetivo do ajuste (menos pausas, mais eficincia) As conseqncias do ajuste

Pode-se tambm utilizar ajustes automticos Java 5.0 Ergonomics

46

Por que ajustar? Metas desejveis: menos pausas e mais

eficincia de processamento (throughput) Melhorar uma pode piorar a outra

Eficincia (capacidade de processamento) a percentagem de tempo total no gasta com

coleta de lixo Inclui tempo gasto com alocao Se a eficincia for maior que 95%, geralmente no

vale a pena fazer ajustes na JVM Pausas

Tempo em que uma aplicao parece no responder porque est realizando coleta de lixo

47

Informaes sobre as coletas

48

Pode-se obter informaes sobre quando ocorrem coletas e como isto afeta a memria usando a opo-verbose:gc Imprime informaes bsicas sobre as coletas (maiores e

menores) de lixo para a sada padro-Xloggc: Usado com verbose:gc grava a informao no arquivo

especificado (importante para ferramentas de anlise de logs)

Exemplos de usojava verbose:gc aplicacao.Main Imprime informaes de coleta na sada padrojava verbose:gc

Xloggc:aplicacao.gc aplicacao.Main Imprime informaes de coleta no arquivo de texto aplicacao.gc

Sada de -verbose:gc Exemplo de sada de grande aplicao servidora

[GC 325407K->83000K(776768K), 0.2300771 secs] [GC 325816K->83372K(776768K), 0.2454258 secs] [Full GC 267628K->83769K(776768K), 1.8479984 secs]

A sada mostra duas coletas menores e uma coleta maior Os nmeros antes e depois da seta (325.407K->83.000K) indicam o

tamanho total de objetos alcanveis antes e depois da coleta Depois de pequenas coletas, a contagem inclui objetos que no esto

necessariamente alcanveis mas que no puderam ser coletados O nmero entre parnteses (776.768K) o total de espao disponvel

(heap total usado menos um dos espaos de sobreviventes e semcontar o espao da gerao permanente)

As coletas menores levaram em mdia 0,24 segundos A coleta maior levou quase dois segundos

49

Informaes mais detalhadas-XX:+PrintGCDetails

Esta opo faz com que a VM imprima mais detalhes sobre a coleta de lixo, como variaes sobre o tamanho das geraes aps uma coleta.

til para obter feedback sobre freqncia das coletas e para ajustar os tamanhos das geraes

Exemplo de uso e resultadojava -XX:+PrintGCDetailsGC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K-133633K (261184K), 0.0459067 secs]]

No parece muito H ainda como obter mais detalhes...

50

Mais detalhes

51

Tempo transcorrido e distribuio de objetos durante a aplicao-XX:+PrintGCTimeStamps Imprime carimbos de tempo relativos ao incio da aplicao.-XX:+PrintTenuringDistribution Detalhes da distribuio de objetos transferidos para a rea estvel. Pode ser usado para estimar as idades dos objetos que sobrevivem

gerao jovem e para descrever a vida de uma aplicao. Exemplos de uso

java -verbose:gc -XX:+PrintGCDetails-XX:+PrintGCTimeStamps -XX:+PrintTenuringDistribution

Sada5.350: [GC Desired survivor size 32768 bytes,

new threshold 1 (max 31)- age 1: 57984 bytes, 57984 total- age 2: 7552 bytes, 65536 total756K->455K(1984K), 0.0097436 secs]

Ferramentas: monitorao JMX

52

O prprio J2SDK possui uma ferramenta simples que fornece informaes grficas sobre a memria usando JMX (Java Management Extensions) Programvel e extensvel

Para habilitar o agente JMX e configurar sua operao, preciso definir algumas propriedades do sistema ao iniciar a mquina virtual

As propriedades podem ser passadas em linha de comando da forma> java Dpropriedade> java Dpropriedade=valor

Se um valor no for fornecido, a propriedade utilizar um valor default (se houver e se for aplicvel)

Propriedades JMX da JVMAs duas principais propriedades so com.sun.management.jmxremote

Habilita o agente remoto JMX Permite monitorao local atravs de um conector JMX usado

pela ferramenta jconsole Os valores podem ser true (default) ou false.

com.sun.management.jmxremote.port=valor Habilita o agente remoto JMX Permite monitorao remota atravs de um conector JMX de

interface pblica disponibilizada atravs de uma porta O valor deve ser o nmero da porta Esta opo pode requerer outras propriedades (veja tabela 1 em

/docs/guide/management/agent.html (documentao J2SE 5.0*)

53* [SDK]

Como habilitar o agente JMX para monitorao local

1) Execute a classe ou JAR da aplicao via JVM passando a propriedade jmxremote> java Dcom.sun.management.jmxremote pacote.MainClass> java Dcom.sun.management.jmxremote jar Aplicacao.jar

2) Obtenha o nmero do processo JVM*> jps3560 Programa (mquina virtual)3740 pacote.MainClass (use este nmero!)3996 Jps

3) Inicie o jconsole com o nmero do processo Use o mesmo usurio que iniciou a aplicao> jconsole 3740

54* jps uma das ferramentas do pacote experimental jvmstat 3.0, que faz parte do J2SDK 5.0

jconsole: memria Execute oGarbage Collector

55

Selecione a rea do heap

desejada

Monitorao remota

56

Para monitorao em tempo de produo, recomenda-se uso remoto (devido ao overhead da aplicao)

Para configurar, preciso obter uma porta de rede livre A porta ser usada para configurar acesso remoto via RMI O sistema tambm criar no registro RMI um nome jmxrmi

Alm da porta de acesso, preciso configurar propriedades de autenticao, dentre outras Para configurao do acesso remoto e outras informaes, veja

/docs/guide/management/agent.html (documentao J2SE 5.0*) Tambm pode-se obter acesso programtico

Para executar o jconsole remotamente, informe o nome da mquina e a porta> jconsole alphard:3740

* [SDK]

Monitorao concisa: jstat

57

Jstat ferramenta do pacote experimental jvmstat Obtm dinamicamente estatsticas de uso das geraes, de

compilao, de carga de classes em tempo real

Para executar, use jstat jvmid Exemplos

> jps13829 Java2Demo.jar1678 Jps.jar

> jstat -gcutil 13829S0 S1 E O P YGC YGCT FGC FGCT GCT12.44 0.00 27.20 9.49 96.70 78 0.176 5 0.495 0.67212.44 0.00 62.16 9.49 96.70 78 0.176 5 0.495 0.67212.44 0.00 83.97 9.49 96.70 78 0.176 5 0.495 0.6720.00 7.74 0.00 9.51 96.70 79 0.177 5 0.495 0.673

Geraes

no. coletas menores

no. coletas maiores

Tempo de coletas menores, completas e total

Visual GC

58

Visual GC a ferramenta visual do pacote experimental jvmstat (distribudo com o SDK 5.0) Mostra geraes, coletas, carga de classes, etc. graficamente preciso baixar o Visual GC separadamente:

http://java.sun.com/performance/jvmstat/visualgc.html

Para rodar, preciso ter o no. do processo da aplicaoa monitorar e o perodo de coleta de amostras (em ms)

Exemplo: monitorao local> jps21891 Java2Demo.jar1362 Jps.jar> visualgc 21891 250

Para acesso remoto, preciso obter o nmero do processo remoto e acrescentar o nome de domnio

> visualgc 21891@remota.com 250

Exemplo: Visual GC

59

Outras ferramentas GC Portal (java.sun.com/developer/technicalArticles/Programming/GCPortal)

Aplicao J2EE que gera grficos e estatsticas Requer instalao em um servidor

GCViewer (www.tagtraum.com) Analisa documentos de texto criados com Xloggc:arquivo Mostra comportamento das geraes e outras informaes Pode executar em tempo real

Profilers Vrios profilers comerciais e gratuitos oferecem informaes e

capacidade de monitorao em tempo real da JVM Comerciais: JProbe, OptimizeIt, JProfiler Gratuitos: NetBeans Profiler, Eclipse Profiler, JRat, EJB,

Cougaar, etc.

60

Exemplo: GC Viewer

61

http://www.tagtraum.com/

Uma coleta maior

Vrias coletas menores

Informaes detalhadas

(pausas, throughput,

memria)

Dados carregados de arquivo gerado com a opo da JVMXloggc:normal.gc

Ferramenta gratuita de

5. Ajuste automtico: ergonomics O objetivo da ergonmica obter a melhor performance

da JVM com o mnimo de ajustes de linha de comando Mais fcil de ajustar (ajuste manual difcil) Uso mais eficiente dos recursos

A ergonmica busca obter, para uma aplicao, as melhores selees de Tamanho de heap Coleta de lixo Compilador de tempo de execuo (JIT)

Ajustes baseados em metas Metas de pausa mxima Capacidade de processamento desejado Alvo: aplicaes rodando em servidores grandes (-server)

62

Server class machine detection Quando uma aplicao inicia, o ambiente de execuo

tentar descobrir se est rodando em uma mquina servidor ou cliente Se tiver pelo menos duas CPUs e pelo menos 2GB de memria

fsica, ser considerada servidora, caso contrrio, cliente

Se estiver em mquina servidora, inicia a JVM Server Inicia mais lentamente, mas com o tempo roda mais rpido

Se estiver em mquina cliente, usa a JVM Client Configurada para melhor performance em ambientes cliente

JVM selecionada ser usada e ser default Sempre ser usada a no ser que seja especificado outra

atravs das opes server ou client

63

Como funciona

64

Usurio especifica Meta de pausa mxima Meta de eficincia mnima Uso mnimo/mximo de memria

Coletor de lixo ajusta automaticamente Aumenta ou diminui tamanho das geraes jovem,

espaos sobreviventes, gerao estvel Altera poltica de promoo para gerao estvel

No garante que metas sero cumpridas So metas, no garantias Como garantir? Seguir estratgias recomendadas

Coletor paralelo: ergonomics As opes abaixo requerem -XX:+UseParallelGC-XX:MaxGCPauseMillis=valor em ms JVM tentar manter pausas mais curtas que o valor especificado Tem precedncia sobre XX:CGTimeRatio-XX:GCTimeRatio=n Define meta de eficincia (throughput). A eficincia

n um valor normalizado que mede a proporo de tempo dedicado aplicao da forma 1:n.

Exemplo: se n for 19, a JVM reservar aplicao 20 (19 + 1) vezes mais tempo que a coleta de lixo (coleta ter 5% do tempo)

Tem menos precedncia que -XX:MaxGCPauseMillis.

tempo de aplicaotempo de coleta de lixo

11 + n

= 1

65

Coletor paralelo: ergonomics

66

-XX:+UseAdaptiveSizePolicy Com esta opo presente, a JVM coleta dados e se baseia

neles para redimensionar as geraes jovem e antiga Esta opo automaticamente ligada se a opo

XX:+UseParallelGC estiver presente. -XX:+AggressiveHeap

Implica no uso das opes XX:+UseParallelGC e XX:+UseAdaptiveSizePolicy

No pode ser usada com XX:+UseConcMarkSweepGC Se esta opo estiver presente, a mquina virtual ir configurar

vrios parmetros buscando otimizar tarefas longas com uso intenso de memria. Usar como base informaes como quantidade de memria disponvel e nmero de processadores.

Esta opo s recomendada para servidores dedicados. Requer pelo menos 256MB de memria fsica

Ergonomics: estratgias

67

1.1 Inicialmente, no escolha um valor mximo para o heap (-Xmx)1.2 Escolha uma meta de eficincia (throughput) que seja suficiente

para sua aplicao Em uma situao ideal, o sistema aumentar o heap at atingir um

valor que permitir alcanar a meta de eficincia desejada.

2.1 Se o heap alcanar o limite e o throughput no tiver sido alcanado2.2 Ento escolha um valor mximo para o heap (menor que a

memria fsica da mquina) e rode a aplicao de novo. Se ainda assim a meta de eficincia no for atingida, alta demais para

a memria disponvel na plataforma

3. Se a meta de eficincia foi alcanada mas as pausas ainda soexcessivas, estabelea uma meta de tempo mximo para pausas Isto pode fazer com que a meta de eficincia no seja mais alcanada Escolha valores que garantam um tradeoff aceitvel

Concluses

68

Mquinas virtuais HotSpot implementam diversos algoritmos clssicos de coleta de lixo Todos baseados em heap dividido em geraes Pr-configurados para situaes, plataformas e usos diferentes Permitem ajustes manuais ou automticos

O ajuste adequado da JVM em grandes aplicaes pode trazer ganhos dramticos de performance Ajuste pode ser simplesmente selecionar a JVM (server ou cliente)

ou definir diversos complexos parmetros manualmente

Para ajustar parmetros (mesmo automticos) preciso conhecer funcionamento dos algoritmos Configurao manual (ex: tamanho de heap) impe conseqncias

que tm impactos em outras reas da performance Metas de ajuste automtico afetam outras metas ou parmetros

6. Apndice: Class data sharing (CDS) Recurso das JVM Client 5.0 para reduzir o tempo de

incio de pequenas aplicaes Durante a instalao, criado um arquivo que ser

compartilhado pelas JVMs que estiverem executando Durante a execuo, mltiplas JVMs compartilharo classes na

memria, evitando carreg-las novamente

Para suportar este recurso, preciso Usar uma plataforma que no seja Windows 95/98/ME Usar o JVM Client e coletor de lixo serial (default em desktops)

Opes da JVM relacionadas-Xshare:[on|off|auto] liga/desliga ou usa CDS se possvel-Xshare:dump gera novamente o arquivo. preciso primeiro

apagar o arquivo em $JAVA_HOME/client/classes.jsa69

Fontes de referncia[SDK] Documentao do J2SDK 5.0[Sun 05] Tuning Garbage Collection with the 5.0 Java Virtual Machine, Sun, 2005[HotSpot] White Paper: The Java HotSpot Virtual Machine, v1.4.1. Sun, 2002.[Apple 04] Java Development Guide for MacOS X. Apple, 2004[Gotry 02] K. Gottry. Pick up performance with generational garbage collection.

JavaWorld www.javaworld.com. Jan 2002[Gupta 02] A. Gupta, M. Doyle. Turbo-charging Java HotSpot Virtual Machine, v1.4

to Improve the Performance and Scalability of Application Servers. Sun, 2002.http://java.sun.com/developer/technicalArticles/Programming/turbo

[Nagarajayya 02] N.Nagarajayya, J.S. Mayer. Improving Java ApplicationPerformance and Scalability by Reducing Garbage Collection Times and SizingMemory Using JDK 1.4.1. Sun Microsystems. Nov 2002

[Holling 03] G. Holling. J2SE 1.4.1 boosts garbage collection. JavaWorld. Mar 2003.[Goetz 03] B. Goetz. Java theory and practice: Garbage collection in the HotSpot

JVM. IBM Developerworks. Nov 2003.

70

2005, Helder da Rochawww.argonavis.com.br

Gerncia de Memria em JavaParte II: Monitorao e configurao da mquina virtual HotSpotOtimizao da JVM HotSpotAssuntos abordadosOpes XX da JVM HotSpot1. Arquitetura da HotSpot JVMTodas as VM HotSpot possuemColeta de lixo em Java: breve histriaColetor de lixo serialHotSpot: arquitetura do heapGerao jovemColeta menorColetas menores: algoritmoColetas menores: exemploA dana das refernciasGerao velha (estvel)Coleta maior (completa)Gerao permanente3. Configurao de memriaTamanho absoluto do heap totalTamanho da gerao permanenteGerao jovem: tamanho absolutoTamanho da pilha de cada threadResumo:ajustes de memriaValores de ajuste absolutosTamanho relativo do heap realExemplo: crescimento do heapExemplo: reduo do heapConseqnciasProporo gerao jovem/velhaGarantia da gerao jovemConseqnciasProporo den/sobreviventesConseqncias3. Seleo do coletor de lixoAlgoritmos utilizadosColeta incremental (Train GC)Coleta da gerao jovemColeta da gerao estvelColetores pr-configuradosOpes de paralelismoAgendamento de coletaModo incremental: CMSTGC vs. CMSTGC vs. CMSQuando a escolha de um coletor de lixo importa para o usurio?Quando usar4. Monitorao de aplicaesPor que ajustar?Informaes sobre as coletasSada de -verbose:gcInformaes mais detalhadasMais detalhesFerramentas: monitorao JMXPropriedades JMX da JVMComo habilitar o agente JMX para monitorao localjconsole: memriaMonitorao remotaMonitorao concisa: jstatVisual GCExemplo: Visual GCOutras ferramentasExemplo: GC Viewer5. Ajuste automtico: ergonomicsServer class machine detectionComo funcionaColetor paralelo: ergonomicsColetor paralelo: ergonomicsErgonomics: estratgiasConcluses6. Apndice: Class data sharing (CDS)Fontes de referncia