JVM - Java é Verboso Mesmo? Parte V

Isso aqui parece mais os filmes do Rocky Balboa...galera old school sabe do que to falando, né não? hehehe
Faaaaaala dominadores do café, tudo bem com vocês?
Sim, eu ando atribulado de coisa pra fazer, mas pra gente fechar esse ciclo e ir tocando assuntos novos, eu trouxe o artigo da vez - último da série - o qual nos fez vir até aqui destrinchando, entendendo o que é a JVM do Javinha das massas!
Foi uma série muito legal de artigos que me deixaram bem feliz de ter feito e compartilhado com vocês! <3

Perdeu algum? então segue o fio de todos os artigos desde o inicio:
Parte I
Parte II
Parte III
Parte IV

Então sem mais delongas... com vocês o motor de execução!

Pensem nele como o motor de um carro, a gasolina é o Java em bytecode, ele entra, circula pelo motor, é injetado em seus componentes. Foi construido para fazer com que o resto da carroceria possa se movimentar, você já viu como um motor funciona, não? então fica aqui uma provocação pra entender como o combustível chega lá e é gerada a energia pra que isso aconteça!

Intepretador- É nessa área que o bytecode chega e é executada uma interpretação para a linguagem nativa do SO em que a JVM está instalada. Só que a problemática dessa área é: não há nenhum tratamento do que é executado dentro do interpretador, por tanto, fatalmente o mesmo trecho de código poderá ser executado inumeras vezes, pois o interpretador vai apenas converter o que chegar até ele, gerando assim uma perda de performance.

Compilador Just In Time (JIT) - Então neste contexto foi proposto o JIT, que é a próxima área do desenho, que busca mitigar esse problema que existe no interpretador para além de manter a performance desejada, ela possa em certos casos até ser melhorada.
Em tempo de execução a JVM carrega os arquivos para a memória e é executado uma análise semântica para determinar quem melhor atende aquele trecho de código, nessa hora, pense em códigos repetidos, o JIT consegue entender que está sendo reexecutado um trecho e o mesmo não mais será jogado para o interpretador, ele ativa um conjunto de códigos nativos diretamente, sem ter que reexecutar o código no interpretador, melhorando assim o tempo no processamento do código que entra para a exeução.

Gerador de código intermediário - responsável por produzir um código intermediário no momento da execução do bytecode que precisará ser executado.
Otimizador de código - Responsável por captar o codigo acima e buscar fazer otimizações na sua execução.
Gerador de código alvo - Responsável por gerar o código fim baseado no sistema operacional onde a JVM se encontra, ou em outros termos, o código nativo.
Perfil - Responsável em buscar por pontos de possíveis execuções repetitivas para assim diminuir o trabalho da área do interpretador.

Coletor de lixo - É o responsável por retirar da memória referências que não possuem mais apontamento nenhum para o código em execução, ou seja, objetos mortos. Pode ser invocado dentro do código da seguinte maneira:

System.gc()

ps: porém essa invocação não tem garantias de que será executada pela JVM.

E por último, dentro da JMV ainda existem o JNI e o Native Method Libraries...

Interface de método nativo (JNI) - Área que fará a interface com a biblioteca de método nativo e disponibilizará para o motor de execução tudo o que precisar para que o código seja efetivamente executado.

Biblioteca de método nativo - Reside a coleção de bibliotecas nativas que são obrigatórias para o pleno funcionamento do motor de execução.

Pessoal, queria agradecer muito quem chegou até aqui! Espero ter sido de alguma maneira útil para você e se tiver alguma dúvida ou sugestão, me manda aqui num comentário ou nas redes sociais.
Um abraço fraterno e até a próxima!!