Java Virtual Machine: ciclo de vida e Class Loaders

Victor Hugo — Mon, 14 Oct 2024 12:03:56 +0000

A Java Virtual Machine (JVM) é o núcleo do ecossistema Java, fornecendo todas as ferramentas essenciais para a execução de código Java. Para compreender plenamente seu funcionamento, é crucial entender o ciclo de vida desse interpretador e as suas implicações para o desempenho e otimização de aplicações Java.

Todo o ciclo de vida da JVM inicia-se com um processo fundamental chamado de "JVM Bootstrapping" que é responsável por construir todo o ambiente de execução e prepará-lo. É nesse contexto que: os argumentos passados na linha de comando são interpretados, o código da JVM é alocado na memória, as estruturas de dados internas da JVM são inicializadas, o gerenciamento de memória se inicia, e por fim a principal thread da aplicação passa a operar. Vamos explorar cada subprocesso descrito nesse parágrafo individualmente:

Os argumentos passados na linha de comando são interpretados

Quando se inicia o programa através da linha de comando, a JVM inicia uma cadeia de processos responsáveis por analisar os argumentos fornecidos, os quais podem incluir parâmetros de inicialização — como por exemplo: -Xms e -Xmx para definir o tamanho mínimo e máximo do heap, área da memória responsável pela alocação e criação de objetos no contexto da aplicação — especificações de debug ou configurações até mesmo do próprio ciclo do Garbage Collector.

Antes de prosseguir, é importante mencionar: com o intuito de simplificação, estaremos analisando o segmento do código que lida com o parsing de argumentos avançados da JVM — os que se iniciam com -XX.

Para se ter mais clareza, vamos utilizar o código open-source da OpenJDK para mais referências. No arquivo arguments.cpp localizado no diretório src/hotspot/share/runtime.arguments.cpp a função que interpreta parâmetros avançados (-XX) pelo CLI é essa:

Fazendo uma breve análise, a função inicia uma verificação para ver se o argumento passado se inicia com + ou -, determinando se a flag for booleana, e também se deve ser desativada ou ativada.

Depois disso, o código começa a extração do nome da flag. Cada caractere é analisado, se não for alfanumerico ou não for _, ele termina (significando que o nome da flag está completa).

Depois de fazer as verificações e identificar o nome da flag, o método JVMFlag* flag = find_jvm_flag(name, name_len); finalmente é invocado para ver se há alguma configuração disponível ao que foi fornecido.

Esse é um pequeno resumo de como os argumentos mais avançados da -XX são parseados. É possível encontrar, no entanto, nesse mesmo arquivo que irei citar, os processos de argumentos que se iniciam com -X que passam por outra função de parsing:

Exemplo da flag: -XMS

ARTIGO EM CONSTRUÇÃO

Explorando as profundezas da JVM: -XX:+PrintCompilation

Victor Hugo — Tue, 26 Sep 2023 22:17:01 +0000

Não é segredo para ninguém que A Máquina Virtual Java, ou JVM (Java Virtual Machine), é uma parte fundamental do ecossistema da linguagem de programação Java. Ela foi revolucionária em sua época, trazendo inovações que transformaram a forma como o software é desenvolvido, executado e distribuído. A JVM é uma máquina virtual que permite que os programas Java sejam executados em diferentes plataformas, proporcionando uma abstração eficiente e independente do sistema operacional subjacente.

Não se limitando apenas a esse escopo revolucionário, mas a JVM também trouxe revoluções no que diz respeito a performance de código, tendo em vista que a abstração por trás da JVM trouxe consigo um conjunto de ferramentas para impressionar nesse contexto: JIT, Garbage Collection, técnicas de inling, otimização de laços, perfil de desempenho. Hoje falaremos sobre sua incrível capacidade de traçar um perfil durante a execução de um código, analisar trechos de códigos que são frequentemente executados durante o tempo de execução e transformá-los em código nativo de máquina.

Para uma introdução à especificação da Máquina Virtual Java (JVM), é crucial entender que ela opera intrinsecamente como se fosse um sistema multithread. Isso significa que tanto a interpretação do bytecode quanto a compilação para código nativo ocorrem em threads separadas, de forma simultânea, no contexto da utilização do compilador "Just in Time" (JIT).

Essa abordagem "multithread" permite que a JVM execute diversas tarefas de forma paralela e otimizada. Enquanto uma thread interpreta o bytecode Java, outra thread compila o código para a forma nativa da máquina. Isso resulta em um desempenho significativamente aprimorado, pois a JVM pode executar código nativo de maneira eficiente e, ao mesmo tempo, manter a portabilidade do código-fonte Java.

Mas o que é exatamente o JIT? Nesse contexto, dentro da JVM, sua função principal é otimizar a execução de programas Java, convertendo o código Java intermediário (bytecode) em código nativo da máquina durante o tempo de execução. Ele compila as partes mais críticas do código para código nativo da máquina e aplica otimizações específicas para tornar a execução mais rápida e eficiente.

No entanto, como podemos visualizar, de forma analítica, esse processo, na prática? Nos vamos utilizar uma flag da máquina virtual denominada de : -XX:+PrintCompilation adicionando ela como argumento no comando de execução java

Por exemplo:
java <jvm args> <class> <cmd args>

Antes de estudarmos profundamente o que essa analisa nos traz, vamos entender a estrutura dessa flag e o que ela significa conceitualmente:

-XX significa que é uma opção avançada, o sinal "+" ou "-" basicamente está apontando se queremos que essa opção seja habilitada ou não, e por fim, a última parte é o nome da opção que passamos de argumento para a JVM. Resumidamente, estamos habilitando (+) uma opção avançada (-XX) chamada de PrintCompilation. Importante mencionar e ressaltar que as flags devem obrigatoriamente respeitar letras maiúsculas e minúsculas, com cada letra inicial sendo maiúscula no que diz respeito ao nome da opção.

Para exemplificar a utilização dessa flag, vamos utilizar o seguinte código, não otimizado, que performa a sequência de Fibonacci até um número inteiro N:

No nosso código Main instanciaremos a classe e executaremos da seguinte forma:

Caso você esteja usando uma IDE como a minha, configure as opções de execução e adicione a flag da JVM que estamos utilizando. No IntelliJ, isso é feito dessa forma:

Quando executarmos o código, nosso output será composto pelo seguinte:

Agora, vamos entender o que é cada coluna e informação presente nessa tela.

A primeira coluna representa o número de milissegundos desde que a máquina virtual foi iniciada. Por exemplo, na primeira linha da imagem, o primeiro valor da primeira coluna é: 558. Isso quer dizer que se passaram 558ms desde o início da JVM naquela instrução específica.

A segunda coluna representa a ordem que o método/instrução/bloco de código foi executado sequencialmente, isto é, em ordem. Na nossa imagem, na primeira linha, aquela instrução foi executada na posição 193, também conhecido como um identificador interno de tarefas.

Observação: o fato de algumas partes não aparecerem em ordem seguidas uma das outras é consequência direta do fato que diferentes blocos de código demoram mais para compilar do que os outros. Isso pode decorrer de problemas de multithreading, complexidade ou até mesmo tamanho.

Note que há um espaço entre a segunda coluna e a próxima, e às vezes ele é preenchido por um símbolo. Eles têm significados:

O símbolo % faz referência a uma técnica chamada de on-stack replacement (OSR). Vamos lembrar que o JIT essencialmente falando é um processo assíncrono, então quando um escopo específico do nosso código é se torna uma opção viável para ser compilado em código nativo de máquina, devido a frequência de sua utilização ou relacionados, esse fragmento de escopo é colocado numa fila. Ao invés de esperar a compilação, a máquina virtual vai continuar interpretando o código em sequência, mas na próxima vez que esse escopo que estamos lidando for chamado, a JVM executará ele em sua versão compilada nativamente. Claro que aqui assumimos que a compilação foi finalizada na thread que sustenta essa fila mencionada. Quando isso acontece, o código estará sendo executado numa parte da memória especial denominada de code cache. Esse símbolo também garante que o escopo está rodando do jeito mais otimizado possível.

O símbolo n indica que a JVM criou um código compilado para tornar mais fácil a chamada a um método que é implementado em linguagem nativa. O s significa que é um método synchronized e ! representa que há tratamento de exceções no escopo referenciado.

Note que na próxima coluna, o elemento está num padrão que varia de 0 até 4. Basicamente, são os níveis de compilação. No nível 0 o bloco de código não foi compilado, ele apenas foi interpretado pela máquina virtual. Nos níveis 1,2, 3, o código foi compilado pelo compilador C1 da máquina virtual. O nível 1 classicamente é o mais otimizado. No nível 4, o trecho mencionado foi compilado pelo C2 e agora ele está na versão mais alta possível de compilação, sendo ele adicionado no code cache.

Observação: nesse artigo em específico, apenas assuma como verdade que existem dois compiladores, C1 e C2, inerentes a máquina virtual e que eles são responsáveis pelo nível de compilação explicado anteriormente. Uma explicação mais detalhada sobre eles será dada no próximo artigo.

A próxima coluna é a referência a instrução da linha, e, por fim, mas não menos importante, o último campo é o tamanho em bytes do bytecode.

Nos próximos artigos nos aventuraremos sobre: code cache, C1, C2 e outras idiossincrasias da Máquina Virtual Java.

Forem: Victor Hugo

Java Virtual Machine: ciclo de vida e Class Loaders

Explorando as profundezas da JVM: -XX:+PrintCompilation