A JVM (Java Virtual Machine) é uma peça fundamental para a plataforma Java. Graças a este recurso, é possível escrever o código e executá-lo em diferentes sistemas operacionais. A diferença dessa abordagem em relação ao processo realizado por outras linguagens, por exemplo o C++, é que não é necessário compilar o código para diferentes S.O's. Apesar de trazer a vantagem citada anteriormente, a abordagem traz alguns trade-off's, entre eles, o impacto na performance. Enquanto no C++ o código é compilado e executado nativamente (binário), no Java é necessário ser compilado para bytecode (linguagem que a JVM entende), interpretado (binário) e executado nativamente. Parece ser pouca a diferença entre as duas linguagens, sendo necessário, no Java, realizar apenas um passo a mais, mas este passo é crucial na performance. Uma das ações tomadas pelos engenheiros e desenvolvedores da plataforma, foi criar um mecanismo que auxilia e provê mais performance na interpretação. Esse mecanismo é conhecido como JIT Compiler ou Just in Time Compiler.

JIT Compiler

Para entender o JIT, é necessário entender, mesmo que em linhas gerais, o que a JVM faz. Seus objetivos são interpretar os bytecodes e gerenciar a memória da aplicação. Por enquanto o foco será no primeiro objetivo.

A imagem acima mostra o processo de compilação do código Java para bytecode, o carregamento para a JVM e a interpretação para binário. O problema destes passos é que, em uma aplicação, o mesmo método ou bloco de código será chamado muitas vezes durante o ciclo de vida da aplicação, sendo necessária a interpretação em cada uma das vezes. Como pode-se imaginar, o impacto na performance cresce exponencialmente e pensando nisso, os engenheiros da plataforma tiveram a ideia do JIT Compiler. O JIT é um processo que ocorre de forma paralela à interpretação (em outra thread) e seu objetivo é transformar (compilar) os trechos de códigos mais executados em linguagem nativa (binário). A diferença da interpretação padrão, citada anteriormente, é que conforme o processo vai sendo executado, vai havendo melhora na compilação até chegar no grau máximo de otimização. Chegando neste grau, a JVM não precisa interpretar mais aquele trecho de código.

Praticando

O processo de compilação em runtime, citado anteriormente, pode ser visto usando a flag -XX:+PrintCompilation no momento da execução do projeto. Para exemplificar, será utilizado o código abaixo:

import java.util.*; public class Principal { public static void main(String[] args) { Integer numeroMaximo = Integer.parseInt(args[0]); Principal principal = new Principal(); principal.guardarNumerosPares(numeroMaximo); } private void guardarNumerosPares(Integer numeroMaximo){ int numero = 0; List<Integer> numerosPares = new ArrayList<>(); while(numero <= numeroMaximo) { if(validarSeEPar(numero)) numerosPares.add(numero); numero++; } } private Boolean validarSeEPar(Integer numero) { if (numero % 2 == 0) return true; return false; } } 

A ideia do código é bastante simples. O usuário fornece um número como argumento e o programa valida quais são os números pares no intervalo de 0 até o número recebido. Para executá-lo com a flag, é necessário o comando java -XX:+PrintCompilation Principal 10. O resultado será:

24 1 3 java.lang.String::isLatin1 (19 bytes) 25 3 3 java.lang.StringLatin1::hashCode (42 bytes) 26 6 3 java.util.ImmutableCollections$SetN::probe (56 bytes) 28 9 3 java.lang.StringLatin1::equals (36 bytes) 28 10 3 java.util.ImmutableCollections$SetN::hashCode (46 bytes) 29 4 3 java.lang.Object::<init> (1 bytes) 29 2 3 java.lang.String::hashCode (60 bytes) 30 5 3 java.lang.Math::floorMod (20 bytes) 30 8 3 java.util.Set::of (4 bytes) 31 11 3 java.util.Objects::requireNonNull (14 bytes) 31 18 4 java.lang.Object::<init> (1 bytes) 31 13 3 java.lang.String::coder (15 bytes) 32 4 3 java.lang.Object::<init> (1 bytes) made not entrant 33 22 3 java.util.ImmutableCollections$SetN$SetNIterator::next (47 bytes) 33 26 n 0 jdk.internal.misc.Unsafe::getReferenceVolatile (native) 33 20 3 java.util.ImmutableCollections$MapN::probe (60 bytes) 34 29 ! 3 java.util.concurrent.ConcurrentHashMap::putVal (432 bytes) 36 16 3 java.util.ImmutableCollections$SetN$SetNIterator::nextIndex (56 bytes) 36 32 3 java.util.HashMap::hash (20 bytes) 37 35 3 java.util.HashMap::putVal (300 bytes) 38 23 3 java.util.ImmutableCollections$SetN$SetNIterator::hasNext (13 bytes) 38 44 4 java.lang.String::hashCode (60 bytes) 38 7 3 java.lang.String::equals (50 bytes) 39 36 3 java.util.HashMap::newNode (13 bytes) 42 2 3 java.lang.String::hashCode (60 bytes) made not entrant 43 46 4 java.util.ImmutableCollections$SetN$SetNIterator::nextIndex (56 bytes) 44 14 1 java.lang.module.ModuleReference::descriptor (5 bytes) 44 16 3 java.util.ImmutableCollections$SetN$SetNIterator::nextIndex (56 bytes) made not entrant 45 12 1 java.lang.module.ModuleDescriptor::name (5 bytes) 46 21 1 java.lang.module.ResolvedModule::reference (5 bytes) 46 44 4 java.lang.String::hashCode (60 bytes) made not entrant 47 33 1 java.lang.module.ModuleDescriptor$Exports::source (5 bytes) 47 31 1 java.util.ImmutableCollections$SetN::size (5 bytes) 

Percebe-se que as informações obtidas são divididas por colunas e o objetivo é entender cada uma delas.

1. O tempo de compilação em milissegundos desde o startup da máquina virtual
2. Ordem de compilação
3. Provê informações sobre a compilação. Ex: "!" significa que houve uma exceção, "n" significa que é um método nativo.
4. Grau da compilação. Os números vão de 0 a 4. 0 significa que não houve compilação, apenas interpretação e 4 que houve compilação e a compilação obteve a máxima otimização.
5. Full qualified name da classe e seu método que passou pela compilação.

Os métodos da aplicação não constam na lista dos métodos compilados, isso acontece pois o tempo de execução do projeto não foi o suficiente para necessitar da compilação otimizada. Aumentando o número para 50000 este comportamento será alterado.

java -XX:+PrintCompilation Principal 50000

//Resto das informações omitidas para facilitar a visualização 68 54 2 Principal::validarSeEPar (19 bytes) 68 52 2 java.lang.Integer::<init> (10 bytes) made not entrant 69 60 4 java.lang.Integer::valueOf (32 bytes) 69 50 1 java.lang.Boolean::booleanValue (5 bytes) 70 55 2 java.lang.Boolean::valueOf (14 bytes) 70 53 2 java.lang.Integer::valueOf (32 bytes) made not entrant 71 61 4 Principal::validarSeEPar (19 bytes) 73 56 2 java.util.ArrayList::add (25 bytes) 75 54 2 Principal::validarSeEPar (19 bytes) made not entrant 76 57 2 java.util.ArrayList::add (23 bytes) 76 41 3 java.util.HashMap$Node::<init> (26 bytes) 77 62 4 java.util.ArrayList::add (25 bytes) 77 14 1 java.lang.module.ModuleReference::descriptor (5 bytes) 

Aumentando o número fornecido para o sistema, o método validarSeEPar passa a ser requisitado mais vezes, sendo necessário uma otimização por parte da JVM. É possível verificar já na primeira linha que o método foi compilado com grau 2 e com o passar do tempo houve uma melhora na compilação, indo para grau 4 na linha 7.

Por conta da execução paralela do JIT, a aplicação pode sofrer com performance momentaneamente, mas a longo prazo, quanto mais a aplicação vai sendo executada, mais a execução vai ficando fluída.

Concluindo ...

A ideia era mostrar sobre como os engenheiros do Java pensaram em melhorar a performance das aplicações e diminuir o trade-off das linguagens compiladas/interpretadas. Essa é só uma pequena parte do que a JVM faz. Ainda há detalhes de como o JIT guarda os métodos, compilados no grau 4, na memória, entre outras questões que ficarão para posts futuros. Dúvidas e sugestões são sempre bem-vindas. Até o próximo!!