CON22150 - The Future of JVM Performance Tuning

The Future of JVM
Performance Tuning
Ricardo S. Ferreira
Java, FMW & Engineered Systems Expert
ricardo.s.ferreira@oracle.com


The following is intended to outline our general product
direction. It is intended for information purposes only, and
may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and
should not be relied upon in making purchasing decisions.
The development, release, and timing of any features or
functionality described for Oracle’s products remains at the
sole discretion of Oracle.


Agenda

JVM, Threads, RAM, Heap e Garbage Collection
Os Algoritmos Clássicos de Garbage Collection
Overview sobre o Algoritmo G1: Garbage-First
Máximo Throughput usando Sockets Direct Protocol
OpenJDK: Contribuindo com o futuro da JVM


Sobre o Palestrante
http://blogs.oracle.com/middlewareplace

Começou a desenvolver
@jricardoferreir
software como profissão
em 1997 (Delphi, C/C++) Procure por “Ricardo Ferreira”
Trabalha com Java desde
2002 (Em especial JEE) Procure por “Ricardo Ferreira”

Red Hat, Progress Soft.
http://blogs.oracle.com/middlewareplace
Respira constantemente
tecnologia na Oracle http://youtube.com/rferreira12345tube
Performance-Driven Guy

JVM, Threads, RAM, Heap
& Garbage Collection (GC)


Visão Geral sobre JVM & Threads

Sistema Operacional

JVM 1 JVM 2


Visão Geral sobre RAM e Heap

Layout de Memória pra JVM

Kernel do
Heap (~75%)
S.O (~10%)

Código
Threads (~5%)
Nativo (~12%)


Visão Geral sobre RAM e Heap

Layout de Memória pra JVM
Heap
Eden Old
Kernel do S.O
Perm Stack

Código Nativo Threads


Visão Geral sobre Garbage Collection (GC)

Objeto Objeto
0x9FFF0
Roots



Objeto Objeto
0x9FFF0
Roots

Foo* foo = new Foo();
delete foo;

foo->doSomething();



Sistema Operacional
GC são threads que executam
em baixa prioridade na JVM
JVM 1 Existem vários tipos de threads
de um GC, mas entre eles:
– Mutators: Responsáveis por
alocar a memória e remanejar
os ponteiros e referências
– Collectors: responsáveis por
fazer a limpeza do espaço de
memória alocado na Heap

Os Algoritmos Clássicos
de Garbage Collection (GC)


Overview sobre os Principais Algoritmos de GC Conhecidos

Algoritmos
de GC Todos esses algoritmos
possuem um objetivo ou
Não Tempo foco particular na JVM
Concorrentes Real
Concorrentes
Algumas implementações
Mark-Sweep Parallel Garbage-First de GC são na prática
uma combinação destes
Mark-Compact Concurrent Deterministic
algoritmos clássicos.
Copying GC
É possível combinar os
Reference algoritmos, desde que
Counting
não ocorra trade-off.

Overview sobre os Principais Algoritmos de GC Conhecidos

Algoritmos
de GC

Não Tempo
Concorrentes Real
Concorrentes

Mark-Sweep Parallel Garbage-First

Mark-Compact Concurrent Deterministic

Copying GC

Reference
Counting


Overview sobre o Algoritmo
G1: Garbage-First


Qual é a “Grande Sacada” do G1?
Principais Características do G1

Executar o GC de forma concorrente
aos threads da aplicação Java
Usar compactação de espaço livre
sem pênalti para o tempo de GC
Usar paralelismo para melhorar o
tempo de resposta da aplicação Java
Possibilitar um tempo de GC mais
próximo do tempo real possível
Possibilitar o uso de áreas de heap
maiores que 6 GB


Overview sobre o G1 (Garbage-First)
Oracle HotSpot Antes do G1
Young Generation
– Dividida em:
Eden Survivors
Eden Space
2 Survivors
Old Generation
– Único e grande espaço contíguo
Old Generation – Desalocação no CMS ocorre no
espaço e de forma concorrente
– “Stop-the-World” para executar uma
compactação total e em paralelo


Overview sobre o G1 (Garbage-First)
Oracle HotSpot Depois do G1
Único espaço contínuo de memória
quebrado em múltiplas regiões de
tamanhos iguais
Tamanho da região dito pela JVM no
startup. Varia entre de 1 MB à 32 MB.


Young GC no CMS (Parte 1)

Young Generation
– Dividida em 1 eden e 2 espaços de
survivors (Foco em objetos recentes)
Old Generation
– Compactado apenas no Full-GC
– Desalocação é feita somente dentro
da região da Old Generation



Durante o Young GC
– Objetos recentes da Young são
evacuados (copiados/movidos) para
Outro espaço de survivor
Old Generation
– Isso implica em “Stop-the-World”



Final do Young GC
– Eden e 1 dos survivors devem estar
completamente vazios (possivelmente)
– Objetos podem ter sido promovidos
para a Old Generation


Young GC no G1 (Parte 1)

Heap da JVM separada em regiões
– Média de regiões: 2 KB
– Cada região com 1 MB ou até 32 MB.
Dá pra alterar com o argumento
-XX:G1HeapRegionSize
Young e Old não precisam ser mais
contíguos. I/O aleatórios nas regiões.


Durante o Young GC
– Objetos recentes da Young são
Uma ou mais regiões de survivor
Regiões do tipo Old Generation
– Isso implica em “Stop-the-World”
– Próximo tempo de GC é calculado


Final da Young GC
– Objetos recentes da Young foram
Zero ou mais regiões de survivor
Regiões do tipo Old Generation
– Regiões do eden e survivor são
potencialmente redimensionados


GC na Old usando CMS :: Depois do Marking (1)
Marcação feita de forma concorrente
– 2 pausas do tipo “Stop-theWorld”
Marcação inicial
Remarcação
– Marca objetos rastreáveis recentes
– Objetos não marcados são os que
foram considerados mortos


Sweeping feito de forma concorrente
– Executa o sweeping em todo o
espaço reservado para Old Gen
– Desaloca objetos mortos que não
foram marcados ou que foram
marcados com a cor branca
– Não realiza nenhuma compactação


Final da fase de sweeping
concorrente
– Todos os objetos não marcados são
desalocados e têm seu espaço limpo


GC na Old usando G1 :: Depois do Marking (1)
– Uma única pausa “Stop-the-World”
Executa remarcação
Completa remarcações pendentes


– Também calcula informações sobre
“sobrevivência” de objetos por região
– Regiões vazias podem ser limpas
imediatamente (como indicado no
exemplo com o símbolo de “X”)


Final da fase de remarcação
– Regiões vazias são limpas
– Informações sobre “sobrevivência” de
objetos atualizadas para todas as
regiões do tipo Old Generation


Limpando regiões do tipo Old Gen
– Escolhe as regiões com baixa taxa de
“sobrevivência” de objetos marcados
– Coleta alguns no próximo GC da
Young Generation


Pode ser que tenham sobrado alguns
objetos nas regiões do tipo Old Gen
– Nas regiões com as maiores taxas de
“sobrevivência” de objetos
– Mas, esses objetos podem ser
coletados mais tarde de acordo com
as regiões não-utilizadas e o tempo
de pausa setado na linha de comando


Principais Diferenças entre o CMS e o G1 (1)

CMS
– Muito difícil de fazer tuning. Muitos parâmetros precisam ser configurados
e muitos algoritmos precisam ser combinados e muito bem entendidos.

G1
– O objetivo é que você defina apenas o tamanho da heap e o tempo de
pausa do GC


Máximo Throughput
usando Sockets Direct
Protocol (SDP)


Você Lembra Disso?

“The
Network
Is the
Computer”
Scott McNealy
Sun Microsystems, 1999


Uso de InfiniBand em Sistemas de HPC (High
Performance Computing)

InfiniBand

Curiosidade:
10 GBs

Uma rede InfiniBand
tradicional opera em 100 MB/s
40GB/s numa latência
média de 1.2 µs 10 MB/s

0 2 4 6 8 10 12


Uso de InfiniBand em Sistemas de HPC (High
Performance Computing)
Redes Tradicionais Rede InfiniBand
Aplicação Aplicação Aplicação Aplicação

I/O Buffer I/O Buffer

Copy Transporte TCP/IP

Kernel

20% Cópia em Buffers Zero Cópia de Buffers
20% em Transport Processing Direct Memory Access
40% Kernel Context Switching Bypass do Kernel

4X mais Throughput, 6X Menos Latência


Suporte a SDP (Sockets Direct Protocol) no
Java 7

sdp.conf
bind 192.168.0.16 *
connect 192.168.0.12 8001
connect 192.168.0.14 1521

java -Dcom.sun.sdp.conf=sdp.conf
-Djava.net.preferIPv4Stack=true com.acme.util.Application


OpenJDK: Contribuindo
com o Futuro da JVM


OpenJDK: Contribuindo com o Futuro da JVM
Principais Recursos
– Feedback sobre assuntos em Geral: hotspot-dev@openjdk.java.net
– Questões gerais sobre o uso do GC: hotspot-gc-use@openjdk.java.net
– Questões de desenvolvimento do GC: hotspot-gc-dev@openjdk.java.net
– Builds “Early Access” do JDK 8: http://jdk8.java.net/download.html

• Java Deployment
• Java Graphics (2D, 3D)
• Java Security Extensions
• Java Performance Tuning
• Java Core Libraries
• Java Quality Assurange


Graphic Section Divider


CON22150 - The Future of JVM Performance Tuning

Recommandé

Recommandé

Contenu connexe

Similaire à CON22150 - The Future of JVM Performance Tuning

Similaire à CON22150 - The Future of JVM Performance Tuning (20)

CON22150 - The Future of JVM Performance Tuning