TODAS AS IMAGENS ao clicar nelas, ELAS AMPLIAM
Qual é o Básico da Arquitetura da JVM?
São os Chamados de Runtime Data Áreas
Toda vez que uma classe é carregada em java, basicamente tem-se na arquitetura da Instancia da JVM operando sobre aquele(s) arquivo.class:
- Program Counter Register
- Java Stack
- Native Method Stacks
- Heap
- Method Área - Runtime Constant Pool -
Área de acesso á Dados em Tempo de execução
- The pc Register : PROGRAM Counter REGISTER (Per-thread)- Cada thread tem seu próprio registro de contagem de Programa. Eles são atualizados depois de cada byteCode executado – os bytecodes se encontram na Method Area- . O pc Register é dividido basicamente em 4 partes:
*frame - É uma referencia ao Frame, contem um ponteiro para o método em execução
(O método em Execução é o primeiro método(Frame ) na Stack da thread)
*optop - Contem um ponteiro para o top da operand Stack é usado para avaliar expressões aritméticas(- Operand Stack da Frame Referente a Stack da thread - )
*pc - o contador de programa,contem O ENDEREÇO DO PROXIMO BYTECODE QUE SERÁ EXECUTADO(Metodo area)
*vars - o registrador de variáveis,contem um ponteiro para as local variables.
(Local Variables da Frame referente a Stack)
Execution Enviroment = É o frame em execução
*Runtime Constant Pool - (Per-class) É uma tabela de Constantes, que são denominados como seqüência de itens, nada mais é que a Constant Pool de um class file mapeado na Runtime Constant Pool(Veja Dynamic Linking se precisar de ajuda)
aload_0
bipush 10 ← pc Register esta aqui agora
Como cada thread tem o seu pc referente no PC register, cada pc register sabe em qual instrução na Method Area esta a thread dele.(Mesmo que for as mesmas intruções (ou seja mesmo objeto em mesmo FRAME))
- Java Virtual Machine Stacks: (Per-thread) ) Normalmente a nomenclatura a Java Virtual Machine Stacks se resume Em "STACK". Cada processo tem ao menos uma thread, uma thread em um contexto geral é um STACK. Então cada thread é um STACK. É usada para passar parâmetros e retornar parâmetros de métodos e manter o estado dos métodos(que são chamados de Stack Frame).
- The garbage-collected heap: (Per-Instance of JVM) Normalmente chamada de Heap,Toda vez que você instancia um objeto , você aloca memoria em HEAP. A linguagem java não deixa você alocar livremente memoria que nem C. Por isso temos uma trilha até la, que é a Referência a Runtime Constant Pool.(Dynamic Linking).
- Native Method Stacks – (Per-thread) São Frequentemente chamados de - "C Stacks" -Porque a maneira mais comum de se escrever métodos Nativos é escrever em c e depois os compilarem em métodos nativos.A jvm em si, conhece várias Linguagens de programação sendo assim, Quando você for fazer algo em java, que realmente não tenha como, você tem suporte ao faze-lo em outras linguagens de programação.
Qual o Ciclo de vida de um Type?
Type = Classe ou Interface
Basicamente: loading, linking, initialization, and unloading
Loading temos em 2 etapas: dynamic linking and dynamic extension
Dynamic Linking and Resolution
Source: http://www.artima.com/insidejvm/ed2/linkmod.html
Um dos mais legais aspectos da Arquitetura de java é o modelo de Link que permite a você projetar suas classes carregando ou ligando classes e interface que ainda não existam quando seu aplicativo foi apenas Compilado.(Ex quando você instancia um objeto, ele so existirá em Runtime porem você o usa.).
Quando você compila um programa em java, você obtém um arquivo compilado para sua classe ou interface. Embora eles sejam independentes eles se Alimentam de Simbólicas conexões a outros arquivos compilados ou a class files na API. Quando você carrega o seu programa , a Jvm carrega as classes do seu programa e as interfaces e vai "pescando" em um processo de Dynamic Linking.
Um class File contem com si todas as referências simbólicas , a Constant Pool. Cada Class File tem a sua Constant Pool, E CADA CLASSE OU INTERFACE CARREGADA TEM UMA VERSÃO INTERNA DA CONSTANT POOL chamada RUNTIME CONSTANT POOL. A Runtime Constant Pool é mapeada da Constant Pool do class File. Assim quando um Class File é carregado todas as Simbólicas referências estão na RUNTIME CONSTANTE Pool dele. - SENDO ASSIM cada Class file tem sua Runtime Constant Pool -
Durante um certo tempo, Se uma Referencia Simbólica precisa ser usada, ELA TEM QUE SER RESOLVIDA. RESOLVER é o processo de achar a entidade identificando pela simbólica Referência e substituir a simbólica referência por uma Referência direta. Como todas as referencias simbólicas moram na Runtime Constant Pool esse processo é frequentemente chamado de constant pool resolution.
Uma Constant Pool é Organizada como uma seqüência de itens. Cada Item tem um index em especial. Uma simbólica referência é um tipo de item que pode existir no Class File(Depende se você usou outras classes, Api etc).As instruções da JVM que usam simbólicas referências especificam o index na Constant Pool onde a simbólica referência a esta. Por exemplo quando você ver o OPCODE getstatic, o qual empura o valor do campo static para a Operand Stack, é seguido pelo index na Constant Pool, exemplo: getstatic #2; Entra-se em um específico index na Constant Pool CONSTANT_Fieldref_info, que Revela o PackageName + className da Classe ao qual o campo reside e o nome e tipo do CAMPO. (No meu caso isso, //Field java/lang/System.out:Ljava/io/PrintStream – LEMBRANDO QUE ISSO é NA MINHA CONSTANT POOL , nesse class file!)
MANTENHA EM MENTE, Cada Class File tem uma RuntimeConstant Pool. A Runtime Constant Pool é carregada de cada Constant Pool de cada Class File.Quando um Opcode se referencia a um item (ex #3) esta se referindo ao 3 item da Constant Pool da classe em que ele esta,que a classe defini a qual método é.
Quando a Jvm vai resolver um link dinâmico, ela faz "n" verificações dez de: Se a classe Existe, até se o campo é realmente static. E se realmente passar em todos, o campo dinâmico é substituído por uma Referência direta.
Constant Pool x Runtime Constant Pool
Cada Class file contem um Constant Pool, quando o class file é carregado pela Jvm, a Constant Pool é mapeada para a Runtime Constant Pool que esta dentro da Method Area.
O bytecode, para otimizar, utiliza referências a constant Pool para economizar a quantidade de bytes utilizados para representar, por exemplo, o nome de uma variável, método ou um objeto a ser carregado. Muito útil também porque as constantes podem ser reutilizadas em todo o código com poucos bytes como referencia em vez do nome completo.
A principal idéia aqui é dar uma introdução a arquitetura da JVM, e principalmente sobre A Method Area, o Pc do pc Register e da Runtime Constant Pool.
Quem acompanha os bytecodes?
Todos bytecodes na Method area são acompanhados pelo pc – do pc Register- (que sabe em qual instrução a thread esta), e quando termina a instrução armazena o endereço da próxima.
aload_0 ← Olha a thread esta nessa instrução
putstatic #3
aload_0
putstatic #3← Agora o pc do PC register aponta para esta Instrução,como ele fez (aload_0) ele ja fica com a referência da próxima
A runtime Constant Pool é mapeada da Runtime de cada class file(para futuramente Resolver todas as constantes - Dynamic Linking -) E é aonde temos os chamados items, Que são resolvidos dos bytecodes da Method Area via Runtime Constant Pool, um exemplo de um item é:
| Slot #12 |
| #4 #5 |
Todos os # fazem referencia a própria tabela de Constant Pool do arquivo, la mesmo ele descreve oque é.
Esses Itens ficam na Constant Pool mapeada para a Runtime Constant Pool. Dentro da METHOD AREA conforme as instruções denominadas pelo pc do PC Register(Claro que existe uma seqüência lógica), se houver a necessidade de resolver e claro que sempre á uma instrução, faz-se Dynamic Linking com a Runtime Constant Pool.
Exemplo:
getstatic #2; < - Sou o pc e estou aqui agora, como resolvo isso?
Quando o pc do Pc Register ler isso na method area, terá que ir na Runtime Constant Pool para fazer o Dynamic Linking.
Pc: Olha Runtime Constant Pool, eu tenho que resolver um item que eu não sei, me diz onde?
Runtime Constant Pool: qual o item?
Pc: #2!
Runtime Constant Pool: isso te retornará um objeto da classe
java/lang/System.out que é um objeto do tipo Ljava/io/PrintStream.
Pc: Obrigado!!!
Claro que é necessário entender Bytecode aqui.
Considerações FINAIS:
(Clique na Imagem para AMPLIAR ELA, nesse contexto fica com baixa resolução)
Informação IMPORTANTE:
Estamos acostumados a desenhar a Stack e Heap de um processo assim:
Lembrando que uma Variável de referência sempre armazena o endereço de memória referente ao objeto na Heap.(Na verdade é uma referência para Constante Pool que depois via Dynamic Linking se tornará realmente uma referência a HEAP).Normalmente quando as pessoas usam o conceito STACK E HEAP, deixam de lado muitas coisas. A idéia de Stack é a de Local variables referentes a um Frame de uma stack.
Frames desse modo:
public class MyClass{
public static void main(String [] args){
}
}
*** Vamos ignorar a parte de argumentos, isso é somente para noção...Então nessa abstração só usaremos os frames como uma forma geral...Porem claro que existe mais em uma Stack como (Parametros, Argumentos etc)public class MyClass{
public static void frame(){
}
public static void main(String [] args){
frame();
}
}
Cada invocação de método, é uma nova Frame na STACK(seja um método static ou não, no exemplo eu usei static para não entrar em instanciação que seria necessário exemplificar com mais áreas de memoria do Frame).
Porem todos os desenhos são conceituais, Na verdade Todo programa quando carregado vira processo, todo processo tem um PROCESS ID, Todo processo tem um PAS(Process Address Space) que realmente contem essas Áreas de memoria mais não desse jeito...Porem é uma boa ilustração!
Não se preocupe com oque não intendeu, próximo capítulo tudo é explicado.
Bom basicamente é isso, próxima seção veremos uma introdução melhor elaborada sobre Stacks.
CYA DUDES.
Nenhum comentário:
Postar um comentário