[ Jakarta One Portuguese - 2021] Desvendando a JVM arquitetura e funcionamento

Transcript

1. Desvendando a JVM Kamila Santos Arquitetura e funcionamento JVM
2. Kamila Santos BACKEND DEVELOPER AME DIGITAL MICROSOFT MVP DEVELOPER TECHNOLOGIES CONTENT CREATOR @KAMILA_CODE
3. O que é a JVM? JVM (Java Virtual Machine) foi criada nos anos 90, ela é a base da plataforma Java e é responsável por tratar todos os SOs e plataformas para a linguagem, ela não conhece a linguagem Java, somente o seu bytecode.
4. O que é a JVM? O bytecode vem no formato .class e são instruções que indicam para a JVM o que deve ser realizado naquela parte da aplicação.
5. Tipos de linguagem -> Linguagem compiladas -> Linguagens interpretadas -> E o Java????????
6. Linguagens compiladas Compilam e transformam o código em binário (linguagem de máquina) seguindo a arquitetura do sistema. Tem como vantagem velocidade de execução pela compilação ser focada na arquitetura. Ex: C e C++
7. Linguagens interpretadas Traduzem cada linha de código em binário conforme a linha é executada. A vantagem dessa abordagem é a portabilidade, que permite executar o código em diversos tipos de arquiteturas sem precisar fazer nenhum tipo de pré-compilação para a arquitetura. Por ex: Ruby e Python
8. E O JAVAAAA? Ela é um misto de linguagem compilada e interpretada. Primeiramente o código é compilado para um formato portátil e intermediário (chamado de bytecode), para somente depois ser interpretado. Dentre as vantagens dessa abordagem podemos citar: type checking (verificação da tipagem), otimização da compilação do código, o bytecode só necessita ser compilado uma vez para chegar o mais próximo do código de máquina e mantém a portabilidade.
9. Apresentando a arquitetura IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
10. Class Loader IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
11. Class Loader Loading Linking Initialization Class Loader é responsável por 3 atividades:
12. Class Loader Quando você compila um arquivo java, ele é convertido em bytecode (arquivo .class). Quando você tenta usar esta classe em seu aplicativo, o class loader o carrega na memória principal.
13. Class Loader - Loading Normalmente, a primeira classe a ser carregada na memória é a classe principal (que contém o método principal). Jvm armazena as seguintes informações no method area:
14. Class Loader - Loading O nome da classe carregada e sua classe pai. Todos os arquivos .class relacionados a esta classe Modificadores, Métodos e Variáveis. 1. 2. 3. Temos 3 carregadores de classes integrados disponíveis em Java:
15. Class Loader - Loading Bootstrap class loader: O carregador de classes raiz. É a superclasse do Extension Class Loader e carrega os pacotes Java padrão (lang, util, net, io ..). Esses pacotes padrão estão presentes no arquivo rt.jar e em outras bibliotecas centrais no diretório $ JAVA_HOME / jre / lib.
16. Class Loader - Loading Extension Class Loader: é a subclasse do Bootstrap Class Loader e a superclasse do Application Class Loader. Carrega as extensões das bibliotecas Java padrão presentes no diretório $ JAVA_HOME / jre / lib / ext
17. Class Loader - Loading Application Class Loader: O último class loader e a subclasse do Extension Class Loader. Carrega os arquivos presentes no caminho de classe. O caminho de classe é definido como o diretório atual do aplicativo.
18. Class Loader - Loading A JVM usa o método ClassLoader.loadClass () para carregar a classe na memória. Tenta carregar a classe com base em um nome totalmente qualificado.
19. Class Loader - Loading Se um class loader pai não puder localizar uma classe, delega o trabalho a um class loader filho. Se o filho não for capaz de carregar a classe, ele lança noClassDefFoundError ou ClassNotFoundException.
20. Class Loader - Linking Depois que uma classe é carregada na memória, ela vai para o processo de linking . O processo de linking envolve combinar os diferentes elementos e dependências do programa.
21. Class Loader - Linking Verificação Preparação Resolução Linking inclui as seguintes etapas: 1. 2. 3.
22. Class Loader - Linking Verificação: Verifica se um arquivo está corretamente formatado e se foi gerado por compilador válido ou não. Se essa verificação falhar, nós recebemos uma runtime exception java.lang.VerifyError. Essa verificação é feita pelo componente ByteCodeVerifier. Quando essa atividade é concluída a classe está pronta para compilação.
23. Class Loader - Linking Preparação: JVM aloca memória para variáveis ​ ​ de classe e inicializa a memória para valores padrão.
24. Class Loader - Linking Resolução: O processo de substituição de referências simbólicas, o processo é feito pesquisando no method area para alocar a entidade de referência.
25. Class Loader - Initialization Nesta etapa, todas as variáveis ​ ​ estáticas são atribuídas com seus valores definidos no código e no bloco estático. Esta etapa é executada de cima para baixo em uma classe de pai para filho na hierarquia de classes.
26. JVM Memory IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
27. JVM Memory Method area Heap JVM language stacks PC registers Native Method stacks Nós temos 5 componentes nessa area:
28. JVM Memory - Method Area Contém todas as informações das classes, como nome, métodos e etc.
29. JVM Memory - Method Area Se a memória disponível nesta área não for suficiente para a inicialização do aplicativo, a JVM lança um OutOfMemoryError.
30. JVM Memory - Method Area Existe apenas uma method area por JVM e é um recurso compartilhado.
31. JVM Memory - Heap Area Aqui estão todos os objetos, suas variáveis ​ ​ de instância e matrizes relacionadas. Esta memória é compartilhada por vários threads.
32. JVM Memory - JVM language Stacks (stack area) Quando uma nova thread é criada na JVM, uma pilha de tempo de execução separada também é criada neste momento. (armazena informações específicas da thread criada, que será destruída assim que a thread for finalizada.
33. JVM Memory - JVM language Stacks Variáveis ​ ​ locais, chamadas de método e resultados parciais são armazenados aqui.
34. JVM Memory - JVM language Stacks Um stackOverFlowError ocorre quando um processo que está sendo executado em uma thread requer um tamanho de pilha muito grande que não está disponível.
35. JVM Memory - JVM language Stacks Para cada chamada de método, uma entrada é feita na pilha de memória (stack frame) quando essa chamada de método é concluída, a stack frame é destruído.
36. JVM Memory - JVM language Stacks Local Variables Operand stack Frame Data A stack frame é dividida em 3 partes:
37. JVM Memory - Local Variables cada frame contém um array de variáveis chamado local variables. Todas local variables e seus valores são armazenados aqui. No tempo de compilação o tamanho desse array é determinado.
38. Diferença entre heap e stack
39. Heap -> armazena objetos complexos -> em um aplicativo, ele é compartilhado por todas as threads -> os dados armazenados na heap podem ser acessados ​ ​ por threads multiplas -> ponteiro para aquele objeto, que é a referência da variável e que está armazenado na pilha
40. Stack -> cada thread tem sua própria stack -> pode ser definida como uma estrutura de dados gerenciada pela JVM -> todas as variáveis ​ ​ locais são criadas na pilha e são automaticamente retiradas da pilha quando você chega ao fechamento do bloco que criou aquela variável -> o dado na stack é restrito para a thread , não pode ser acessada por outras threads da aplicação.
41. JVM Memory - Operand stack Cada frame contém uma pilha LIFO chamada operand stack. Atua como um workspace em tempo de execução para performar operações intermediárias.
42. JVM Memory - Frame Data Armazena todos os símbolos correspondentes ao method area e armazena as informações do bloco catch em caso de exceptions.
43. PC (Program Counter) Registers Cada thread tem o seu próprio PC registers para armazenar o endereço do que está sendo executado no momento na JVM.
44. PC (Program Counter) Registers Quando a instrução é executada, o PC register é atualizado com a próxima instrução.
45. JVM Memory - Native Method Stacks Para cada nova thread, uma nova native method stack é alocada.
46. Execution Engine IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
47. Execution Engine Interpreter Just-In-Time Compiler(JIT) Garbage Collector Na execution engine nós temos 3 partes:
48. Execution Engine A execution engine executa os bytecodes (arquivo .class) Lê o bytecode linha a linha Então usa os dados e informação presentes na área de memória para executar instruções.
49. Execution Engine - Interpreter O interpreter é responsável por ler e executar o bytecode linha a linha. Devido a esse processo linha a linha o interpreter é uma das etapas mais demoradas.
50. Execution Engine - Interpreter Quando um método é chamado múltiplas vezes,a cada vez é necessário uma nova interpretação.
51. Execution Engine - JIT Compiler O JIT compiler ve quais partes do código são executadas com maior frequência. (Principalmente quais métodos são chamados com maior frequência). A execução desse código pode ser acelerada se o método já for compilado para código nativo de máquina. A parte do código que já estiver em código de máquina vai rodar mais rápido que o bytecode interpretado.
52. O que é o código de máquina nativo mesmo? O código executável que é compreendido pelo SO, na compilação o bytecode é convertido para o código de máquina nativo (isso em um thread separada), enquanto isso a JVM continua usando a versão interpretada.
53. JIT Compiler seu prinicipal objetivo é recompilar o bytecode anteriormente gerado em tempo de runtime,buscando por possíveis melhorias para sua execução em código nativo. Nesse processo estão envolvidos dois tipos de compiladores: Client Compiler (C1) e o Server Compiler (C2).
54. C1 Compiler voltado para aplicações no lado cliente com inicialização mais rápida, o compilador busca por hot methods (mais utilizados) para fazer otimizações simples. Short lived applications também se benficiam da rapidez do C1, levando em conta que nao houve tempo de "aprender" como otimizar aquele código inicialmente.
55. C2 Compiler voltado para aplicações do lado sever, tem como objetivo analisar e monitorar por mais tempo o comportamento do código dentro da nossa aplicação, buscando por pontos críticos e para fazer a otimização posteriormente. As otimizações são mais agressivas já que a análise é mais rigorosa também. Métodos compilados pelo C2 são mais rápidos que os compilados pelo C1.
56. Tiered Compilation Surgiu no Java 7 e no Java 8 se tornou default, tem como estratégia começar somente com o interpretador de forma rápida e depois começar a fazer pequenas otimizações usando o C1 para saber quais são os hot methods.
57. Tiered Compilation Depois desse tempo inicial de execução, o funcionamento da app e dos hot methods ganha maior relevância e o C2 é chamado para fazer as otimizações mais avançadas. o Tiered Compilation é dividido em 5 níveis:
58. Níveis da Tiered Compilation Nível 0 - usa somente o modo de interpretação Nível 1 - usa o C1 de modo simples sem nenhuma análise de comportamento (profiling) Nível 2 - usa o C1 com um profiling limitado e moderado
59. Níveis da Tiered Compilation Nível 3 - usa o C1 com um processo de profiling completo Nível 4 - usa o C2 com o mesmo profiling do nível anterior.
60. Segmented Code Cache Surgiu no Java 9 com maneiras de organizar e separar os tipos de código compilados em cache, é uma área onde JVM armazena seu bytecode compilado em código nativo. Chamamos cada bloco de código nativo de nmethod , ele pode ser um método Java completo ou parte dele.
61. Segmented Code Cache Ele tem um tamanho fixo, quando encher o JIT será desligado (a app não vai parar). Caso isso aconteça iremos receber o erro: "CodeCache is full… The compiler has been disabled" e teremos uma grande queda de desempenho. Para melhorar isso temporariamente, podemos mudar seu tamanho tendo as seguintes opções:
62. Segmented Code Cache InitialCodeCacheSize – tamanho inicial do code cache, 160K default ReservedCodeCacheSize – valor padrão é 48MB CodeCacheExpansionSize – quantidade que pode ser adicionada ao code cache, 32KB or 64KB
63. Segmented Code Cache Para saber como está o uso do code cache temos a opção – XX:+PrintCodeCache e teremos uma saída semelhante a essa: CodeCache: size=xyzKb used=xyz max_used=xyz free=xyzKb
64. Segmented Code Cache É dividido em 3 partes: non-method segment: aramzenda o código interno relacionado à JVM, como o interpretador de bytecode. Por default, este segmento tem cerca de 5 MB. Além disso, é possível configurar o tamanho do segmento por meio do argumento -XX: NonNMethodCodeHeapSize
65. Segmented Code Cache É dividido em 3 partes: profiled-code segment: armazenda o código ligeiramente otimizado com tempos de vida potencialmente curtos. Tem como tamanho padrão 122 MB , podemos alterá-lo por meio do argumento -XX: ProfiledCodeHeapSize
66. Segmented Code Cache É dividido em 3 partes: non-profiled segment : armazena o código totalmente otimizado com tempos de vida potencialmente longos. Tem cerca de 122 MB por padrão. Este valor é, obviamente, configurável por meio do argumento -XX: NonProfiledCodeHeapSize
67. Execution Engine - Garbage Collector O Garbage Collector (GC) é responsável gerenciar de modo automático a alocação de memória da aplicação coordenando junto ao SO a quantidade de memória utilizada, a eliminação de objetos que já não estão mais sendo utilizados e assim determinar quando será necessário realizar uma limpeza para disponibilizar mais recursos.
68. Execution Engine - Garbage Collector Existem vários algoritmos de limpeza que se combinam na implementação do GC. Os mais comuns são:
69. Mark and Sweep Que percorre os objetos em memória sinalizando os que possuem referência e depois os percorre novamente limpando aqueles que não estão marcados
70. Copying Semelhante ao anteriror, porém no final copia de um buffer para outro ,organizando e memóeira durante a cópia e removendo a fragmentação existente.
71. Generational Separa a memória em gerações na qual cada passagem do GC pelo objeto incrementa sua "idade", tendo como resultado uma separação da seguinte maneira:
72. Garbage Collector - Generational Eden S0 S1 Old Generation (tenured) Permanent Generation Young Generation Survival Space Imagem baseada de :https://www.oracle.com/webfolder/technetwork/tutorials/ obe/java/gc01/index.html e do Livro Jornada Java , cap Garbage Collection, imagem 44.1
73. Eden -> onde todo novo objeto é alocado. Survivor Space -> onde ficam os objetos que já "sobreviveram" às primeiras limpezas e possuem referências válidas. Old Generation -> objetos com idade mais avançada. Permanent generation -> armazena os metadados de classes e métodos (a partir do JDK 8 essa sessão foi removida e as informações que antes ficavam nela ficam alocadas diretamente em memória).
74. Execution Engine - Garbage Collector GC é executado automaticamente pela JVM em intervalos regulares mas também pode ser disparado chamando System.gc ()
75. Execution Engine - Garbage Collector Serial GC Parallel GC Garbage First (G1) GC Nós temos 3 tipos de GC:
76. Execution Engine - Garbage Collector Serial GC: é destinado para aplicações pequenas que executam em ambiente single-thread,é a implementação mais simples do GC. O argumento da JVM para usar o Serial Garbage Collector é -XX:+UseSerialGC
77. Execution Engine - Garbage Collector Parallel GC: é o tipo default de GC da JVM. Usa múltiplas threads para garbage collection, mas permanece pausado quando a aplicação está em execução. O argumento da JVM para usar o Parallel Garbage Collector é - XX:+UseParallelGC.
78. Execution Engine - Garbage Collector Garbage First (G1): recomendado para aplicações multi-thread que tem grande espaço de heap disponível.A heap é dividida em espaços de tamanho iguais, G1 identifica as regiões com maior “lixo” e faz a coleta nessa região O argumento da JVM para usar o G1 Garbage Collector é -XX:+UseG1GC
79. Native Method Interface IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
80. Native Method Interface É uma interface (como uma ponte) Que interage com as Native Method Libraries e provem as native libraries (C, C++).
81. Native Method Interface Isso permite que a JVM chame bibliotecas C/C++ e seja chamada por bibliotecas C/C++
82. Native Method Libraries IMAGEM DE: HTTPS://WWW.GURU99.COM/JAVA-VIRTUAL-MACHINE-JVM.HTML
83. Native Method Libraries São bibliotecas que são escritas em outras linguagens de programação (como assembly, C e C++). Essas bibliotecas geralmente estão presentes na forma de arquivos .dll ou .so.
84. Referências https://www.freecodecamp.org/news/jvm-tutorial-java-virtual-machine- architecture-explained-for-beginners/ https://www.geeksforgeeks.org/jvm-works-jvm-architecture/ https://www.guru99.com/java-virtual-machine-jvm.html Imergindo na JVM - otávio Santana Jornada Java - Capitulos - capitulos 43 e 44 https://www.baeldung.com/jvm-code-cache https://deviniciative.wordpress.com/2020/02/06/desmistificando-otimizacao- de-jvm/ https://www.udemy.com/course/java-application-performance-and-memory- management/
85. Obrigada :) https://www.linkedin.com/in/kamila-santos-oliveira/ https://www.instagram.com/kamila_code/ https://www.youtube.com/channel/Kamilacode