Arquitetura de Maquinas Virtuais - UNICAMP

UNIVERSIDADE ESTADUAL DE CAMPINAS

1

Instituto de Computao

MO401 Arquitetura de Computadores I Prof. Dr. Ricardo Pannain

Arquitetura de Mquinas Virtuais

Daniele Junqueira Frosoni Diego Zuquim Guimares Garcia Fabiano Costa Teixeira

Maio, 2005

2

3

NDICE1. INTRODUO ..............................................................................................................................................................5 1.1. 1.2. 2. CENRIO .................................................................................................................................................................5 OBJETIVO ................................................................................................................................................................7

ESTRUTURA DA MQUINA VIRTUAL JAVA.......................................................................................................8 2.1. 2.2. 2.3. 2.4. 2.5. ARQUIVO DE CLASSE ...............................................................................................................................................9 TIPOS DE DADOS .....................................................................................................................................................9 MEMRIA JVM .....................................................................................................................................................12 QUADROS ..............................................................................................................................................................15 EXCEES .............................................................................................................................................................16

3.

ARQUITETURA CLR ................................................................................................................................................17 3.1. 3.2. 3.3. MEMRIA CLR .....................................................................................................................................................19 ESTADO GLOBAL ...................................................................................................................................................19 ESTADO DE MTODO .............................................................................................................................................20

4.

CONJUNTO DE INSTRUES JVM ......................................................................................................................22 4.1. 4.2. 4.3. 4.4. 4.5. 4.6. 4.7. 4.8. 4.9. INSTRUES LOAD/STORE......................................................................................................................................27 INSTRUES ARITMTICAS/LGICAS ....................................................................................................................27 INSTRUES DE CONVERSO DE T IPOS .................................................................................................................28 INSTRUES DE OBJETOS ......................................................................................................................................28 INSTRUES DE PILHA...........................................................................................................................................29 INSTRUES DE DESVIO ........................................................................................................................................29 INSTRUES DE MTODOS ....................................................................................................................................29 INSTRUES DE EXCEES ...................................................................................................................................30 INSTRUES DE SINCRONIZAO ..........................................................................................................................30

5.

CONJUNTO DE INSTRUES CLR.......................................................................................................................30 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. TIPOS DE DADOS SUPORTADOS .............................................................................................................................30 TIPOS NUMRICOS .................................................................................................................................................32 TIPOS PONTEIROS ..................................................................................................................................................32 DADOS AGREGADOS..............................................................................................................................................33 CONTROLE DE FLUXO ............................................................................................................................................35 INVOCAO DE MTODOS .....................................................................................................................................36

6.

FORMATO DO ARQUIVO DE CLASSE JAVA .....................................................................................................36 6.1. 6.2. 6.3. 6.4. ESTRUTURA DO ARQUIVO DE CLASSE ...................................................................................................................36 CONSTANT POOL ....................................................................................................................................................38 ESTRUTURA DE CAMPOS .......................................................................................................................................42 ESTRUTURA DE MTODOS .....................................................................................................................................43

46.5. 6.6. 6.7. 6.8. 6.9. 6.10. 7. ESTRUTURA DE ATRIBUTOS ...................................................................................................................................44 RESTRIES NO CDIGO JVM...............................................................................................................................46 VERIFICAO DE ARQUIVO DE CLASSE .................................................................................................................48 VERIFICAO DE BYTECODE ..................................................................................................................................49 MANIPULADORES DE EXCEES ...........................................................................................................................51 FORMATO DE ARQUIVO CLR ................................................................................................................................51

EXECUO DE PROGRAMAS ...............................................................................................................................52 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. EXECUO DE PROGRAMAS JVM .........................................................................................................................52 CARGA DE TIPOS ...................................................................................................................................................52 LIGAO DE TIPOS ................................................................................................................................................54 INICIALIZAO DE T IPOS .......................................................................................................................................55 OBJETOS ................................................................................................................................................................56 DESCARGA DE T IPOS .............................................................................................................................................57 EXECUO DE PROGRAMAS CLR..........................................................................................................................58

8.

COMPILAO............................................................................................................................................................61 8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10. 8.11. 8.12. 8.13. USO DE CONSTANTES E VARIVEIS LOCAIS, E DE CONSTRUES DE CONTROLE ....................................................61 ARITMTICA ..........................................................................................................................................................63 ALCANANDO O CONSTANT POOL..........................................................................................................................63 MAIS CONSTRUES DE CONTROLE ......................................................................................................................63 RECEBENDO ARGUMENTOS ...................................................................................................................................64 INVOCANDO MTODOS ..........................................................................................................................................65 TRABALHAR COM INSTNCIAS DE CLASSE ............................................................................................................67 ARRAYS.................................................................................................................................................................69 COMPILANDO SWITCHES .......................................................................................................................................70 OPERAES NA PILHA DE OPERANDOS..................................................................................................................72 MANIPULANDO EXCEES ....................................................................................................................................72 COMPILAR FINALMENTE ........................................................................................................................................76 SINCRONIZAO ....................................................................................................................................................78

9.

LINHAS DE EXECUO E MONITORES.............................................................................................................79 9.1. 9.2. 9.3. SINCRONIZAO ....................................................................................................................................................79 TRAVAMENTO DE OBJETOS ...................................................................................................................................81 SUPORTE NO CONJUNTO DE INSTRUES ..............................................................................................................82 REFERNCIAS BIBLIOGRFICAS...................................................................................................................84 CONJUNTO DE INSTRUES JVM COMPLETO ......................................................................86 MQUINAS VIRTUAIS IMPLEMENTADAS EM HARDWARE ..............................................110

10.

APNDICE A. APNDICE B.


5

1. IntroduoSegundo Meijer (2001) e Venners (1997), mquina virtual (virtual machine) uma abstrao que define um modelo computacional, e tambm uma implementao, construda sobre outra mquina virtual, ou diretamente em hardware. Recentemente, o termo tem sido empregado, usualmente, para referenciar uma plataforma de software que existe em mltiplas plataformas de hardware, e prov uma camada de abstrao que possibilita aos programadores desenvolverem programas sem considerar o hardware no qual eles sero executados. Em sua forma tpica, uma mquina virtual pode ser considerada uma camada de software, conforme ilustrado abaixo: Programas Compilados Mquina Virtual Plataforma Computacional (Hardware e Sistema Operacional)Figura: localizao de uma mquina virtual em um sistema computacional. Fonte: Venners (1997) [adaptada].

Como exemplos de mquinas virtuais podem ser citadas as mquinas: Sun Microsystems Java Virtual Machine, para a tecnologia Java; Microsoft Common Language Runtime, para a tecnologia .NET; Perl Foundation Parrot Code Virtual Machine, para as tecnologias Perl e Python.

Mquinas virtuais so empregadas para solucionar problemas importantes, considerando o modelo computacional corrente, tais como, compartilhar o mesmo hardware entre muitos programas atravs do particionamento do mesmo, possibilitar que o software seja portvel entre vrios sistemas operacionais, bem como, executar programas legados em plataformas computacionais atuais. A palavra virtual do termo mquina virtual empregada com o sentido de simulao, pois, desejado que a mquina virtual comporte-se como se fosse a mquina real. Portanto, apesar de existirem diversos tipos de implementao de mquinas virtuais, em sua forma mais bsica, uma mquina virtual a simulao de uma mquina que na verdade no est presente. O termo virtual refere-se de fato ao conjunto de instrues. Existem diversos tipos de mquinas virtuais, mas, o tema comum entre elas a idia de simular um conjunto de instrues de uma mquina. Cada mquina virtual utiliza um conjunto de instrues virtual que o usurio tem acesso, e ento a mquina virtual mapeia essas instrues virtuais para o conjunto de instrues real do computador.

1.1. CenrioDe acordo com Venners (2000) e Microsoft (2001), as infra-estruturas de dispositivos microprocessados portteis e ubquos, e de redes de interconexo de computadores, proporcionam um ambiente que gera desafios ao desenvolvimento da computao. As tecnologias baseadas em abstraes de mquinas, tais como Java e .NET, so inerentemente apropriadas para tal ambiente, possibilitando a distribuio em redes, e a execuo em ambientes computacionais heterogneos, de programas independentes de plataforma.


6

Figura: applet Java e rede de computadores. Fonte: Venners (2000).

A tecnologia de maior destaque a arquitetura Java, que engloba: linguagem de programao Java; mquina virtual Java (Java Virtual Machine JVM); interface de programao de aplicao Java (Java Application Programming Interface Java API); formato de arquivo de classe Java (Java Class File Format).

Esses quatro componentes da arquitetura Java relacionam-se da seguinte maneira: o programa expresso em arquivos fonte na linguagem de programao Java, chamando mtodos nas classes que implementam a Java API para acessar recursos de sistema; tais arquivos so compilados para arquivos de classe Java, que so executados na JVM, invocando as rotinas da Java API. Em conjunto, a JVM e a Java API constituem uma plataforma abstrata para a qual os programas so compilados. Consequentemente, programas podem ser executados em quaisquer plataformas reais para as quais a Plataforma Java (Java Platform) tenha sido implementada.

Figura: ambiente de programao Java. Fonte: Venners (2000).


7

1.2. ObjetivoEste trabalho foca em um dos quatro componentes da arquitetura Java: a JVM; objetivando, por meio dessa mquina especfica, desenvolver conceitos que permeiam o assunto de mquina virtual, uma estratgia adotada por diversas tecnologias, com o objetivo de suportar a independncia de plataforma computacional de forma transparente aos desenvolvedores de software. JVM um computador abstrato, cuja especificao define caractersticas que toda implementao de mquina virtual Java deve possuir, mas, flexvel, possibilitando opes por parte dos projetistas de implementaes de mquinas virtuais. A flexibilidade da especificao possibilita que a JVM possa ser implementada em variados dispositivos, conforme indica Gough (2001). Toda JVM deve ser apta a executar instrues JVM (bytecodes), entretanto, o projetista pode escolher que tcnica utilizar para a execuo dos bytecodes. Alm disso, uma JVM pode ser implementada completamente em software, com graus variados em software e hardware, ou mesmo completamente em hardware. A principal tarefa da JVM carregar arquivos de classe (.class) e executar os bytecodes contidos neles. Uma JVM contm basicamente dois componentes: carregador de classe (class loader), que carrega arquivos de classe tanto do programa quanto da Java API, sendo que, apenas as classes da Java API que so necessrias de fato para o programa em execuo so carregadas na mquina virtual; motor de execuo (execution engine), que responsvel pela execuo dos bytecodes. O motor de execuo pode variar em implementaes JVM diferentes: na variao mais simples, o motor de execuo apenas interpreta os bytecodes um por vez; em outra variao, mais rpida, mas que porm requer mais memria, o motor um compilador JIT (just-in-time), que compila os bytecodes de um mtodo para cdigo nativo de mquina na primeira vez que o mtodo invocado, e o armazena em cache, de forma que possa ser reutilizado na prxima vez que o mesmo mtodo for invocado; uma variao intermediria do motor de execuo o otimizador adaptativo, tcnica na qual a mquina virtual inicia com a interpretao dos bytecodes, mas monitora a execuo do programa, procurando identificar as pores de cdigo mais utilizadas, que so compiladas para cdigo nativo e otimizadas, com o restante do cdigo permanecendo como bytecodes, os quais a mquina virtual continua interpretando; as trs primeiras tcnicas so empregadas quando a JVM implementada em software, mas, em uma JVM construda sobre um chip que executa bytecodes Java nativamente, o motor de execuo est de fato embutido no chip.

Figura: JVM implementada em software sobre um sistema operacional hospedeiro. Fonte: Venners (2000).


8

Em Java existem dois tipos de mtodos: mtodos Java, que so escritos na linguagem Java, compilados para bytecodes, e armazenados em arquivos de classe; mtodos nativos, que so escritos em alguma outra linguagem (por exemplo, C e C++), compilados para o cdigo nativo de mquina de um processador especfico, e armazenados em bibliotecas de ligao dinmica.

Mtodos Java so independentes de plataforma, ao contrrio de mtodos nativos, e, portanto, um programa que utiliza mtodos nativos torna-se dependente de plataforma. Quando um programa Java em execuo chama um mtodo nativo, a mquina virtual carrega a biblioteca dinmica que contm o mtodo nativo e o invoca. Mtodos nativos proporcionam uma conexo entre um programa Java e o sistema operacional, possibilitando acesso direto aos seus recursos. No decorrer do trabalho, temas tratados em relao JVM sero abordados no contexto da CLR, com o objetivo de apresentar a arquitetura dessa mquina virtual, e, possibiltar a comparao entre as tecnlogias. O Microsoft .NET Framework contm a CLR (Common Language Runtime), uma implementao do padro CLI, conforme indica Meijer (2001). A CLI (Common Language Infrastructure), descrita no padro ECMA Standard 335, define a plataforma bsica para a arquitetura .NET. A mquina virtual CLR proporciona as mesmas vantagens discutidas com relao JVM. Entretanto, uma das principais vantagens apresentadas refere-se ao desenvovlimento cross-language, ou seja, a possibilidade de escrever programas em diversas linguagens de programao, tais como, C#, J#, VB.NET, dentre outras. Os cdigos fontes so compilados para uma linguagem intermediria comum, a MSIL (Microsoft Intermediate Language), que desempenha o mesmo papel dos bytecodes Java. A CLR executa instrues MSIL por meio de um compilador JIT (diferentemente da JVM a CLR nunca atua como interpretador). Apesar de a JVM poder suportar desenvolvimento cross-language, devido a algumas restries do framework Java, o suporte muitas vezes difcil e algumas vezes incompleto. Isso conseqncia do compromisso de projeto relativo segurana da mquina virtual. A CLR apresenta as seguintes caractersticas, no presentes na JVM: objetos na pilha (records, unions), chamada por referncia, argumentos variveis, apontadores, matrizes, checagem de overflow, tail calls, tipos de dados de tamanho nativo. Isso a torna mais apropriada para utilizao com variadas linguagens de programao.

2. Estrutura da Mquina Virtual JavaA figura abaixo demonstra a estrutura da JVM. Os componentes sero apresentados a seguir.


9

Figura: arquitetura interna da mquina virtual Java. Fonte: Venners (2000).

2.1. Arquivo de ClasseSegundo Lindholm (1996) e Venners (1996, 2000), toda implementao JVM deve ser capaz de ler arquivos de classe e realizar as operaes neles especificadas. Quando um programa fonte escrito em Java compilado, gerado um cdigo independente de hardware e sistema operacional. Esse cdigo armazenado geralmente, mas no necessariamente, em um arquivo de classe. Esse arquivo , analogamente, comparado a um arquivo executvel (.exe) gerado pelo compilador da linguagem C++ para ambientes Microsoft Windows. Eles se diferem principalmente na forma de execuo, pois o arquivo executvel executa diretamente na plataforma, ao passo que o de classe executado em uma mquina virtual.

2.2. Tipos de DadosAssim como a linguagem de programao Java, a JVM trabalha com tipos de dados primitivos e de referncias. Ambos os tipos de dados podem ser armazenados em variveis, passados como argumentos, retornados por mtodos e manipulados como valores primitivos e valores de referncia. O conjunto de instrues da mquina virtual Java distingue os tipos dos operandos de uma instruo. Por exemplo, para as instrues de adio de dois valores so oferecidas as instrues: iadd, ladd, fadd e dadd (as instrues JVM so apresentadas no Apndice A), que so, respectivamente, utilizadas para efetuar somas de valores dos tipos int, long, float e double.


10

Figura: tipos de dados da mquina virtual Java. Fonte: Venners (2000).

A mquina virtual contm explicitamente suporte a objetos. Um objeto tanto uma instncia de classe dinamicamente alocada, como um vetor (array). Objetos so referenciados por meio do tipo de dado reference, que pode ser considerado um ponteiro para objeto. 2.2.1. Tipos de Dados Primitivos e Valores Os tipos de dados primitivos suportados pela JVM so: numrico, booleano (boolean) e endereo de retorno (returnAddress). O tipo numrico consiste dos tipos inteiro e ponto-flutuante. So eles: byte: composto por 8 bits, sinalizado por complemento a dois; short: composto por 16 bits, sinalizado por complemento a dois; int: composto por 32 bits, sinalizado por complemento a dois; long: composto por 64 bits, sinalizado por complemento a dois; char: composto pos 16 bits, no sinalizado, com a finalidade de representar caracteres Unicode; float: cujos valores so elementos do conjunto de valores de ponto-flutuante em preciso simples, ou, onde suportado, o conjunto de valores de ponto-flutuante em preciso simples com expoente estendido; double: cujos valores so elementos do conjunto de valores de ponto-flutuante em preciso dupla, ou, onde suportado, o conjunto de valores de ponto-flutuante em preciso dupla com expoente estendido.

Os valores do tipo de dados boolean representam os dois valores de tabela-verdade: verdadeiro (true) e falso (false). Os valores de um tipo de dados returnAddress so ponteiros para opcodes de instrues JVM. Dos tipos primitivos manipulados pela JVM, somente o tipo returnAddress no diretamente associado a um tipo da linguagem de programao Java.


11

2.2.2. Tipos de Dados Integrais e Valores Os valores para variveis dos tipos numricos suportados pela JVM so os mesmos utilizados na linguagem de programao Java: byte: de 128 a 127; short: de 32768 a 32767; int: de 2147483648 a 2147483647; long: de 9223372036854775808 a 9223372036854775807; char: de 0 a 65535.

2.2.3. Tipos de Dados Ponto-Flutuante e Valores Os tipos ponto-flutuante so float e double, que so conceitualmente associados aos formatos de 32 bits (preciso simples) e 64 bits (preciso dupla), especificados no padro IEEE 754 (Standard for Binary Float-Point Arithmetic, ANSI/IEEE Std. 754-1985). O padro IEEE 754 inclui no somente nmeros com sinais positivos e negativos, como tambm zeros positivos e negativos, infinitos positivos e negativos, e o Not-a-Number Value, que utilizado para representar o resultado de certas operaes invlidas como, por exemplo, a diviso por zero. Toda implementao JVM requer o suporte de dois conjuntos padres de valores de pontoflutuante, chamados float value set e double value set. Uma implementao da mquina virtual Java pode, opcionalmente, suportar conjuntos de valores de ponto-flutuante com expoente estendido, chamados: float-extended-exponent value set e double-extended-exponent value set. 2.2.4. Tipo de Dados returnAddress e Valores O tipo returnAddress (endereo de retorno) utilizado pelas instrues jsr, ret, e jsr_w da mquina virtual (descritas no Apndice A). Os valores de um tipo returnAddress so ponteiros para opcodes das instrues da mquina virtual Java. Ao contrrio dos tipos primitivos numricos, o tipo returnAddress no corresponde a nenhum tipo de dados da linguagem de programao Java e no pode ser modificado pelo programa em execuo. 2.2.5. Tipo de Dados Boolean e Valores Embora a mquina virtual defina um tipo boolean ela no tem instrues exclusivas para tratar esse tipo de dados. Sendo assim, instrues na linguagem Java que utilizam tipo de dados boolean so compiladas para trabalhar com o tipo de dados int. Dessa forma, o compilador mapeia os valores true e false para os valores inteiros 1 e 0, respectivamente. 2.2.6. Tipo de Dados Reference e Valores Existem trs gneros de tipos de referncia (reference): classe, array e interface. Seus valores so referncias para instncias de classe, arrays, e instncias de classe ou arrays que implementam uma interface. Alm disso, pode ser atribudo o valor nulo (null) a uma referncia, o qual no aponta para nenhum objeto.


12

2.3. Memria JVMA mquina virtual Java define vrias reas de dados de tempo de execuo (run-time data reas), que constituem a memria da mquina, e so utilizadas durante a execuo de um programa. Algumas dessas reas so criadas durante a inicializao da mquina virtual e so destrudas somente quando essa se encerra. Outras reas de dados so para linhas de execuo (threads), tendo como tempo de vida o mesmo da thread. 2.3.1. Registrador Program Counter A mquina virtual suporta a execuo de vrias threads simultaneamente. Cada thread da JVM executa o cdigo de um nico mtodo, referido como o mtodo corrente para a thread. Dessa forma cada thread sendo executada possui seu prprio registrador program counter (PC), que armazena, caso o cdigo atualmente processado no seja nativo, o endereo da instruo JVM que est sendo executada. Caso o cdigo executado pela thread seja nativo, o valor do PC indefinido. 2.3.2. Pilha Cada thread executada na mquina virtual possui uma pilha (stack) privada, criada conjuntamente com a thread, com a finalidade de armazenar quadros de mtodos (frames). Essas pilhas tm um funcionamento anlogo quelas utilizadas em linguagens convencionais, como no caso da linguagem de programao C, armazenam variveis locais, resultados parciais, dentre outros valores. Pelo fato da pilha no ser manipulada diretamente, exceto para empilhar (push) e desempilhar (pop) frames, ela pode ser alocada dinamicamente, no necessitando assim de memria contgua para armazen-la. A mquina virtual permite que essa pilha tenha tamanho fixo ou variado (dependendo da necessidade da execuo ela pode ser expandida ou contrada). Para o caso de ela ter o tamanho fixo, esse valor pode ser definido pelo programador. Para o caso de ser variado os tamanhos mnimo e mximo tambm podem ser definidos. Alguns erros podem ocorrer em funo da utilizao da pilha: se a execuo da thread requer um tamanho de pilha maior que o permitido dispara uma exceo de StackOverflowError; para o caso de expanso dinmica, se no momento da expanso no houver memria suficiente para efetuar a operao dispara uma exceo de OutOfMemoryError. 2.3.3. Heap A mquina virtual Java contm uma rea heap que compartilhada entre todas as threads. a partir dessa rea de dados de tempo de execuo que memria para todas as instncias alocada. A rea heap criada no momento de inicializao da mquina virtual. Ela pode ter um tamanho fixo pr-definido, ou ser expandida ou contrada dinamicamente, de acordo com a necessidade da computao corrente (podendo ter seus tamanhos mnimo e mximo pr-definidos). A memria para a rea heap no precisa ser contgua. Essa rea gerenciada por um sistema de gerenciamento de armazenamento automtico, mais conhecido como coletor de lixo (garbage collector). As sees da rea heap utilizadas para armazenamento de objetos so recuperadas pelo garbage collector automaticamente, de forma que objetos nunca so desalocados da rea heap explicitamente. Se for necessrio um tamanho de rea heap maior que aquele que pode ser disponibilizado pelo sistema de gerenciamento de armazenamento, a mquina virtual dispara uma exceo de OutOfMemoryError.


13

2.3.4. rea de Mtodo A JVM tem uma rea de mtodo (method area), que compartilhada entre todas as suas threads. A rea de mtodo anloga rea de armazenamento para cdigo compilado de uma linguagem de programao convencional, ou, anloga ao segmento de texto (text segment) em um processo Unix. A rea de mtodo armazena as estruturas especficas de cada classe, tais como, o conjunto de constantes de tempo de execuo (runtime constant pool), dados de campo (field data), dados de mtodo (method data), cdigo para mtodos e construtores, incluindo mtodos especiais utilizados na inicializao de instncias (objetos) e tipos (classes e interfaces). Essa rea criada na inicializao da mquina virtual, e apesar dessa rea ser logicamente parte da reas heap, implementaes JVM podem decidir a respeito da coleta de lixo e da compactao dessa rea. Seu tamanho pode ser fixo ou expansvel com limites definidos, e a memria no precisa ser contgua. A condio de exceo relacionada com essa rea acontece se memria na rea de mtodo no pode ser disponibilizada para satisfazer uma requisio de alocao. Para tal situao, a JVM dispara uma exceo de OutOfMemoryError.

Figura: runtime data areas compartilhadas entre todas as threads. Fonte: Venners (2000).

2.3.5. Runtime Constant Pool Uma rea de dados de conjunto de constantes de tempo de execuo (runtime constant pool) uma representao de tempo de execuo da tabela de constantes em um arquivo de classe. Portanto, cada tipo (classe ou interface) possui seu runtime constant pool, que armazena diversos tipos de constantes, variando de literais numricos conhecidos em tempo de compilao a referncias de campos e mtodos que devem ser resolvidas em tempo de execuo. A rea de runtime constant pool possui uma funo similar funo de uma tabela de smbolos para uma linguagem de programao convencional, apesar de ela conter uma variao mais ampla de dados. Cada runtime constant pool alocada na rea de mtodo da JVM, a partir da criao de um tipo pela JVM. A construo de reas de runtime constant pool tambm sujeita a erros, e portanto, quando da criao de um tipo, se a construo da rea de runtime constant pool requerer mais memria que pode ser disponibilizada na rea de mtodo, a mquina virtual dispara uma exceo de OutOfMemoryError.


14

2.3.6. Pilhas de Mtodos Nativos Uma JVM pode utilizar pilhas convencionais, coloquialmente chamadas C Stacks, para suportar mtodos nativos (mtodos implementados em outras linguagens de programao que no Java). Se a implementao JVM no suportar carga de mtodos nativos, no necessrio alocar reas de dados para pilhas de mtodos nativos. Caso contrrio, pilhas de mtodos nativos so alocadas por thread, quando de sua criao. Uma aplicao Java em execuo pode utilizar outras reas de dados criadas para mtodos nativos. Quando um mtodo nativo invocado, a execuo entra em um outro mundo, onde as estruturas e restries de segurana da mquina virtual no podem mais ser totalmente preservadas. Um mtodo nativo pode utilizar reas de dados de tempo de execuo da mquina virtual ou utilizar os registradores nativos do processador real, alocar memria nativa e utilizar qualquer tipo de pilha nativa. Mtodos nativos so inerentes implementao. Projetistas de implementaes JVM so livres para escolherem os mecanismos que sero utilizados para habilitar uma aplicao Java a acessar mtodos nativos. Quando uma thread invoca um mtodo nativo ela dinamicamente faz uma ligao (link) e diretamente invoca o mtodo. Uma maneira de se fazer isso estendendo dinamicamente a prpria mquina virtual com o cdigo nativo. como se a mquina virtual estivesse invocando um mtodo prprio. Se a implementao da interface de cdigo nativo utilizar o modelo de ligao da linguagem C, ento as pilhas de mtodos nativos sero C Stacks. Nesse modelo, quando um programa C invoca uma funo C, os parmetros so empilhados em certa ordem, o controle passado funo que desempilha esses parmetros, efetua o processamento e empilha o resultado de retorno. A figura abaixo ilustra uma forma de invocao de um mtodo nativo. Um mtodo Java invoca outro mtodo, o qual invoca um mtodo nativo. Esse mtodo nativo invoca ou outro que por sua vez, atravs da interface de mtodos nativos, invoca um mtodo Java.

Figura: pilha para uma thread que invoca mtodos Java e nativos. Fonte: Venners (2000).

As pilhas de mtodos nativos podem ser de tamanho fixo ou varivel. Uma implementao JVM pode prover ao programador ou ao usurio controle sobre os limites de tamanho da pilha. As excees tratadas pela JVM para o caso de pilhas de mtodos nativos so as mesmas para o caso de


15

pilhas de mtodos Java (StackOverflowError e OutOfMemoryError).

2.4. QuadrosQuadros (frames) so utilizados para armazenar dados e resultados parciais, fazer ligao dinmica, retornar valores para mtodos e disparar excees. Um novo quadro criado toda vez que um mtodo invocado e destrudo quando a execuo do mtodo termina. Ele armazenado na pilha da thread associada. Cada quadro possui seu prprio array de variveis locais, sua prpria pilha de operandos e uma referncia para o run-time constant pool da classe do mtodo atual. Somente um quadro, aquele do mtodo em execuo, ativo durante um determinado ponto na execuo de uma thread. Esse quadro referido como quadro corrente (current frame) e seu mtodo como mtodo corrente (current method). A classe na qual o mtodo corrente definido dita como classe corrente (current class). Operaes em variveis locais e pilha de operandos so feitas com referncia ao quadro corrente. Um quadro deixa de ser corrente quando um mtodo invoca um outro mtodo ou quando conclui sua execuo. Quando um mtodo invocado, criado um novo quadro, e esse se torna corrente quando o controle transferido para o novo mtodo. No retorno do mtodo, o quadro corrente retorna o resultado de sua invocao de mtodo, se houver algum, ao quadro anterior. Ento esse quadro descartado e o anterior passa a ser o corrente.

Figura: runtime data areas exclusivas para cada thread. Fonte: Venners (2000).

2.4.1. Variveis Locais Cada quadro contm um array de variveis chamado local variables. Seu tamanho definido em tempo de compilao e inserido na representao binria da classe juntamente com o cdigo do mtodo associado. Uma varivel local pode armazenar dados dos tipos: boolean, byte, char, short, int, float, reference, returnAddress, long e double.


16

Variveis locais so endereadas atravs de indexao. O ndice da primeira varivel local 0. Um nmero inteiro pode ser considerado como um ndice do vetor de variveis locais se, e somente se, ele for maior ou igual a 0 e menor que o tamanho do array. Valores para tipos long e double ocupam duas posies do array. Sendo assim, para enderelos devemos utilizar o menor valor de ndice das duas posies ocupadas. O array de variveis locais utilizado para a passagem de parmetros a um mtodo. A posio 0 do array utilizada para armazenar a referncia ao objeto do qual pertence o mtodo invocado (utilizado pelo this na linguagem Java) e os demais parmetros so passados da posio 1 do array em diante. 2.4.2. Pilha de Operandos Cada quadro possui uma pilha chamada operand stack. A mquina virtual Java fornece instrues para armazenar dados nessa pilha, e tambm outras que retiram valores da pilha, efetuam operaes com eles e devolvem os resultados na pilha. Essa pilha utilizada para preparar os parmetros a serem passados a um mtodo, bem como para armazenar o resultado do mtodo. Por exemplo, a instruo iadd efetua a adio de dois valores do tipo int. Essa instruo requer que os dois operandos da adio estejam nas duas posies mais altas da pilha atravs de instrues de empilhamento executadas anteriormente. Ambos os valores so retirados da pilha, adicionados e o resultado empilhado de volta. Para empilhar um valor do tipo long ou double a pilha incrementada em duas unidades. Para os demais tipos ela incrementada em apenas uma unidade. 2.4.3. Ligao Dinmica Cada quadro contm uma referncia para o run-time constant pool da classe do mtodo corrente para suportar ligao dinmica (dynamic linkage) do cdigo do mtodo. O cdigo contido no arquivo de classe refere-se a mtodos a serem invocados, e variveis a serem acessadas via referncias simblicas. A ligao dinmica traduz essas referncias simblicas a mtodos em referncias concretas a mtodos, carregando classes, se necessrio, para resolver os smbolos no definidos, e tambm traduz acessos a variveis em deslocamentos (offsets) apropriados na estrutura de armazenamento. 2.4.4. Concluso de Invocao de Mtodos A concluso de invocao de um mtodo pode acontecer de duas maneiras: Concluso normal: a invocao de um mtodo conclui normalmente se no foi disparada nenhuma exceo ou, caso tenha sido disparada, essa tenha sido tratada corretamente. Se um mtodo concludo normalmente, ento o resultado pode ser retornado para o mtodo que o invocou. Nesse caso, o quadro do mtodo que o invocou restaurado e o resultado da execuo do mtodo invocado armazenado no topo da pilha do quadro atual; Concluso brusca: a invocao de um mtodo termina bruscamente quando a execuo causa uma exceo e essa no tratada. Um mtodo que conclui dessa forma jamais retorna o resultado ao mtodo que o invocou.

2.5. ExceesDisparar uma exceo implica em uma transferncia de controle imediata a partir do ponto onde


17

a exceo foi disparada. Essa transferncia de controle pode concluir abruptamente, um por um, comandos mltiplos, invocaes de construtores, avaliaes de inicializadores estticos e de campo e invocaes de mtodos regulares. Na linguagem Java, o processo continua at encontrar uma clusula catch que manipula o valor disparado. Caso contrrio, a thread corrente termina. Nos casos em que uma clusula finally utilizada, ela executada durante a propagao de uma exceo disparada a partir do bloco try associado e qualquer bloco catch associado, mesmo se nenhuma clusula catch que manipula a exceo for encontrada. Conforme implementado pela JVM, cada clusula catch ou finally de um mtodo representada por um manipulador de exceo (exception handler). Um exception handler responsvel por: especificar os limites de deslocamentos nos bytecodes que implementam o mtodo para os quais o exception handler ativo; descrever o tipo de exceo que o exception handler capaz de manipular; especificar a localizao do cdigo que trata a exceo.

Uma exceo emparelha com um exception handler se o deslocamento da instruo que causou a exceo est dentro dos limites de deslocamentos do exception handler e o tipo da exceo a mesma classe ou uma sub-classe da classe de exceo que o exception handler manipula. Quando uma exceo dispara, a JVM procura por um exception handler compatvel no mtodo corrente. Caso algum seja encontrado, o sistema desvia para o cdigo tratador da exceo especificado pelo exception handler compatvel. Caso a JVM no encontre exception handler compatvel no mtodo corrente, a invocao do mtodo corrente concluda abruptamente. Em uma concluso de invocao de mtodo abrupta, a pilha de operando e as variveis locais da invocao de mtodo corrente so descaradas, e seu frame desempilhado, restabelecendo o frame do mtodo que o invocou. A exceo ento disparada novamente no contexto do frame do mtodo invocador, e assim por diante. Caso nenhum exception handler compatvel seja encontrado antes do topo da corrente de invocaes de mtodos ser alcanado, a execuo da thread onde foi disparada a exceo terminada. Os exception handlers para cada mtodo so armazenados em uma tabela no arquivo de classe Java. Em tempo de execuo, quando uma exceo disparada, a JVM procura por exception handlers o mtodo corrente na ordem em que eles aparecem na tabela de exception handler correspondente no arquivo de classe, comeando do incio da tabela. Como os comandos try so estruturados, um compilador Java pode ordenar as entradas na tabela de exception handler de forma que, para qualquer exceo disparada, e qualquer valor de PC (program counter) no mtodo, o primeiro exception handler compatvel com a exceo disparada corresponde clusula catch ou finally mais interna no mtodo. A JVM no demanda qualquer ordem para as entradas da tabela de exception handler de um mtodo. A semntica de manipulao de exceo da linguagem Java implementada com a cooperao apenas do compilador, de forma que, quando arquivos de classe so gerados por outros meios, o procedimento de procura definido pela JVM garante que todas as mquinas virtuais apresentaro comportamento consistentemente.

3. Arquitetura CLRDe acordo com Meijer (2001) e Microsoft (2001), ao prover servios, tais como, carga de classe, verificao, compilao JIT, e gerenciamento de cdigo, a CLR cria um ambiente para execuo de cdigo chamado Virtual Execution System.


18

A figura a seguir mostra os principais elementos da arquitetura da CLR, com os vrios caminhos que podem ser seguidos atravs desse ambiente de execuo.

Figura: arquitetura CLR. Fonte: Microsoft (2000).

Em muitos casos, o cdigo-fonte compilado em MSIL. O cdigo MSIL carregado, compilado em cdigo nativo on-the-fly utilizando um compilador JIT, e executado pela mquina real. No caso de cdigo confivel, a etapa de verificao pode ser omitida. O motor de meta-dados CLR (metadata engine) possibilita ao compilador de cdigo-fonte


19

inserir meta-dados no arquivo PE conjuntamente com o cdigo MSIL compilado. PE significa Portable Executable, o formato utilizado para arquivos executveis (EXE) e bibliotecas de ligao dinmica (DLL). Durante a carga e a execuo, esses meta-dados provem informao necessria para registro, depurao, gerenciamento de memria, e segurana. Tambm indicado no diagrama, est o fato de que classes da .NET Framework Class Library podem ser carregadas pelo carregador de classe juntamente com cdigo nativo, MSIL ou OptIL (um sub-conjunto de instrues MSIL). Outro caminho de execuo que pode ser escolhido envolve pr-compilao para cdigo nativo utilizando um compilador backend. Essa opo pode ser escolhida se compilar cdigo em tempo de execuo, ou seja, compilao JIT, no aceitvel devido a restries de performance. Conforme indicado no diagrama, cdigo nativo pr-compilado desvia da verificao e compilao JIT. Pelo fato de cdigo nativo pr-compilado no ser verificado, ele deve ser considerado cdigo completamente confivel para que possa ser executado.

3.1. Memria CLRMemria, no contexto de mquina virtual, relaciona-se com a memria de processo regular onde a mquina virtual opera. Conceitualmente, na CLR, assim como na JVM, essa memria simplesmente um array de bytes. O ndice nesse array o endereo de um objeto de dados. A CLR acessa objetos de dados na memria atravs de instrues ldind.* e stind.*. Um dos objetivos de projeto da CLR foi esconder detalhes de um frame (quadro) de invocao de mtodo do gerador de cdigo MSIL. Isso permite que a CLR, e no o gerador de cdigo MSIL, possa escolher a conveno de invocao e o layout de pilha mais eficientes. Para alcanar essa abstrao, o quadro de invocao integrado CLR. As definies de estado de mquina a seguir refletem essas escolhas de projeto, onde estado de mquina consiste primariamente de estado gloabal e estado de mtodo. O alinhamento de tipos de dados maiores que um byte depende do processador alvo. fortemente recomendado que tipos primitivos sejam alinhados para o tamanho do tipo, ou seja, tipos com tamanho igual a dois bytes comeam em endereos pares, com quatro bytes, em endereos divisveis por quatro, e com oito bytes, em endereos divisveis por oito. Existe um prefixo de instruo, unaligned.. Ele pode imediatamente preceder uma instruo ldind, stind, itblk, ou cpblk, e indica que o dado pode no estar alinhado, requerendo que o compilador JIT gere cdigo que no poder causar erros de no-alinhamento de memria. Para tipos de dados maiores que um byte, a ordem de byte dependente do processador alvo. Cdigos que dependem da ordem de byte no podem ser executados em todas as plataformas. O arquivo de cdigo MSIL pode ser marcado para indicar que ele depende de um tipo de ordem de byte particular.

3.2. Estado GlobalA CLR gerencia mltiplos threads de controle concorrentes, mltiplas heaps gerenciadas, e um espao de endereamento de memria compartilhado. Uma thread de controle pode ser imaginada como uma lista separadamente ligada de estados de mtodos, onde um novo estado criado e ligado de volta ao estado corrente por uma instruo de invocao de mtodo, seguindo o modelo tradicional de seqncia de invocao baseada em pilha. A figura a seguir ilustra o modelo de estado de mquina, que inclui threads de controle, estados de mtodos, e mltiplas heaps em um espao de endereamento compartilhado.


20

Figura: modelo de estado de mquina CLR. Fonte: Microsoft (2000).

3.3. Estado de MtodoO estado de mtodo, mostrado na figura abaixo, uma abstrao do quadro de mtodo. Argumentos e variveis locais so parte do estado de mtodo, mas eles tambm podem conter Object References para dados armazenados em quaisquer das heaps gerenciadas.

Figura: estado de mtodo CLR. Fonte: Microsoft (2000).

Um estado de mtodo descreve o ambiente no qual um mtodo executa (na terminologia


21

convencional de compiladores, ele corresponde a um super-conjunto da informao capturada no invocation stack frame). O estado de mtodo CLR consiste dos seguintes itens: um apontador de instruo (instruction pointer - IP). O IP aponta para a prxima instruo MSIL a ser executada pela CLR no mtodo presente; uma pilha de avaliao (evaluation stack). A pilha est vazia quando do incio da execuo do mtodo. Seu contedo inteiramente local ao mtodo e preservado atravs de instrues de chamada, ou seja, se o mtodo corrente chama outro, uma vez que o mtodo chamado retorne, o contedo da pilha de avaliao do mtodo invocador continua como estava no momento da invocao. A pilha de avaliao no enderevel. Em qualquer instante possvel deduzir que tipo est armazenado em qualquer localizao da pilha; um array de variveis locais (local variable array), iniciando no ndice zero. Valores desse array so preservados atravs de chamadas, assim como acontece com a pilha. Uma varivel local pode conter qualquer tipo de dados. Entretanto, um elemento de array particular deve ser utilizado de uma maneira consistente em relao ao tipo. O endereo de uma varivel local individual pode ser obtido utilizando a instruo ldloca; um array de argumentos (argument array), iniciando no ndice zero. Esse array contm os valores dos argumentos de entrada do mtodo corrente. Eles podem ser lidos ou escritos por indexao lgica. O endereo de um argumento pode ser obtido por meio da instruo ldarga. Alm disso, o endereo de um argumento obtido implicitamente pela instruo arglist para uso em conjunto com iterao typesafe atravs de listas de argumento de tamanho varivel; um methodInfo handle. Ele contm informao read-only sobre o mtodo. Em particular, ele mantm a assinatura do mtodo, os tipos de suas variveis locais, e dados sobre seus manipuladores de exceo; um local memory pool. A CLR contm instrues para alocao dinmica de objetos do local memory pool (localloc). A memria alocada no local memory pool enderevel, e recuperada no momento de finalizao de contexto de mtodo; um return state handle, que utilizado para restaurar o estado de mtodo no retorno do mtodo corrente. Tipicamente, o estado restaurado o do mtodo invocador, mas, tanto o estado de retorno, como o apontador de instruo de retorno, podem ser ajustados pelo gerenciador de cdigo; um security descriptor. Ele no acessvel diretamente pelo cdigo gerenciado, mas, o sistema de segurana o utiliza para manter aes de segurana (assert, permit-only, e deny).

A especificao da CLR (CLI) define uma arquitetura na qual as quatro reas do estado de mtodo, ou seja, array de argumentos de entrada, array de variveis locais, local memory pool e pilha de avaliao, so reas logicamente distintas. Entretanto, implementaes CLI podem mapear essas reas em um array de memria contguo, mantido como um quadro de pilha convencional na arquitetura alvo subjacente. 3.3.1. Pilha de Avaliao Associado a cada estado de mtodo est uma pilha de avaliao. Muitas instrues CLR obtm seus argumentos da pilha de avaliao e armazenam seus valores de retorno nessa pilha. Alm disso, argumentos para outros mtodos e seus valores de retorno tambm so armazenados na pilha de avaliao. Quando uma invocao de mtodo realizada, os argumentos para o mtodo chamado tornamse o array de argumentos de entrada para o mtodo. Isso pode requerer uma cpia de memria, ou


22

simplesmente um compartilhamento dessas duas reas pelos dois mtodos. A pilha de avaliao constituda de slots que podem manter qualquer tipo de dado. O estado de tipo da pilha, ou seja, a profundidade da pilha e tipos de cada elemento na pilha, em qualquer ponto em um programa deve ser idntico para todos os possveis caminhos de fluxo de controle. Por exemplo, um programa que possui um lao que repete um nmero desconhecido de vezes e empilha um novo elemento na pilha a cada iterao proibido. 3.3.2. Variveis Locais e Argumentos Arrays que mantm variveis locais e argumentos de entrada fazem parte de cada estado de mtodo. Assim como a pilha de avaliao, cada elemento desses arrays pode conter qualquer tipo de dados. Associado a cada mtodo esto meta-dados que especificam: se a memria de variveis locais e memory pool dever ser inicializada quando entrar no mtodo; o tipo de cada argumento e o tamanho do array de argumentos de entrada; o tipo de cada varivel local e o tamanho do array de variveis locais.

A CLR insere padding de acordo com o apropriado para a arquitetura alvo. Ou seja, em arquiteturas de 64 bits, todas as variveis locais devem ser alinhadas a 64 bits, enquanto que em outras elas podem ser alinhadas a 8, 16 ou 32 bits. 3.3.3. Local Memory Pool Associado com cada estado de mtodo est um local memory pool. Memria pode ser explicitamente alocada do local memory pool utilizando a instruo localloc. Toda memria no local memory pool recuperada na sada de mtodo, e essa a nica forma de recuperar memria, pois, no h instrues para liberar memria que foi alocada durante a execuo do mtodo corrente. O local memory pool utilizado para alocar objetos cujos tipos e tamanhos no so conhecidos em tempo de compilao, e os quais o programador no deseja alocar na heap gerenciada. Como o local memory pool no pode ser contrado durante o tempo de vida do mtodo, uma linguagem de implementao no pode utiliz-lo para alocao de memria de propsito geral.

4. Conjunto de Instrues JVMDe acordo com Lindholm (1996) e Venners (1996, 2000), um stream de bytecodes de um mtodo uma seqncia de instrues para a JVM. Cada instruo consiste de um opcode de um byte seguido por zero ou mais operandos. O opcode (cdigo de operao) indica a operao a ser realizada. Operandos fornecem informao extra necessitada pela JVM para realizar a operao especificada pelo opcode. O prprio opcode indica se ele ou no seguido por operandos, e a forma que os operandos possuem, caso haja algum. Muitas instrues JVM no possuem operandos, e, portanto, consistem de apenas um opcode. Um mnemnico definido para cada bytecode. Os mnemnicos podem ser imaginados como uma linguagem de montagem (assembly) para a mquina virtual. Por exemplo, existe uma instruo que faz com que a JVM empilhe um valor zero na pilha. O mnemnico para essa instruo iconst_0, e seu bytecode 60. Essa instruo no recebe operandos.


23

Outra instruo faz com que a execuo do programa desvie incondicionalmente para frente ou para trs na memria. Essa instruo requer um operando, um offset sinalizado de 16 bits. Adicionando o offset localizao de memria corrente, a JVM pode determinar a localizao de memria para onde desviar. O mnemnico para essa instruo goto, e seu bytecode a7.

Figura: bytecodes e mnemnicos de instrues JVM. Fonte: Venners (1997).

Dependendo do opcode, a JVM pode referir-se a dados armazenados em outras reas alm de, ou ao invs de, operandos que acompanham o opcode. Quando executa uma instruo, a JVM pode utilizar entradas na constant pool corrente, nas variveis locais do frame corrente, ou valores localizados no topo da pilha de operando do frame corrente. O motor de execuo abstrato da JVM funciona executando bytecodes uma instruo por vez. Esse processo acontece para cada thread (instncia de motor de execuo) do programa em execuo na JVM. Um motor de execuo de uma JVM busca (fetch) um opcode e, se o opcode tem operandos, busca os operandos. Ele executa a ao requerida pelo opcode, e ento busca outro opcode. A execuo de bytecodes continua at que uma thread conclua, tanto retornando ao mtodo invocador, quanto no capturando uma exceo disparada. Ignorando excees, a iterao mais interna de uma mquina virtual o seguinte: faa { busca uma instruo; se (operandos) busca os operandos; executa a ao para o opcode; } enquanto (houver instrues) O motor de execuo pode encontrar uma instruo que requer uma invocao de mtodo nativo. Nessas situaes, o motor de execuo tentar obedientemente invocar o mtodo nativo. Quando o mtodo retornar, se ele completar normalmente, ou seja, sem disparar exceo, o motor de execuo continuar executando a prxima instruo no stream de bytecodes. Mtodos nativos podem ser considerados extenses customizadas pelo programador para o conjunto de instrues da JVM. Se uma instruo requerer uma invocao de um mtodo nativo, o motor de execuo invoca o mtodo nativo. Executar o mtodo nativo como se a JVM executasse a instruo. Quando o mtodo nativo retorna, a mquina virtual passa para a prxima instruo. Se o mtodo nativo dispara uma exceo, a JVM segue os mesmos passos para tratar a exceo que ela segue quando qualquer instruo JVM dispara uma exceo. Parte do trabalho de executar uma instruo a determinao da prxima instruo a ser executada. Um motor de execuo determina o prximo opcode a ser buscado em uma de trs maneiras possveis: para muitas instrues, o prximo opcode a ser executado segue diretamente o opcode corrente e seus operandos, se houver algum, no stream de bytecodes; para algumas instrues, tais como goto e return, o motor de execuo determina o prximo


24

opcode como parte da execuo da instruo corrente; se uma instruo dispara uma exceo, o motor de execuo determina o prximo opcode a buscar procurando por uma clusula catch apropriada.

Diversas instrues podem disparar excees. A instruo athrow, por exemplo, dispara uma exceo explicitamente. Essa instruo a forma compilada de um comando throw no cdigo fonte Java. Sempre que uma instruo athrow executada, ela disparar uma exceo. Outras instrues disparam excees apenas quando determinadas condies so encontradas. Por exemplo, se a JVM descobre que o programa est tentando realizar uma diviso inteira por zero, ela disparar uma ArithmeticException. Isso pode acontecer, por exemplo, enquanto executando quaisquer das quatro instrues idiv, ldiv, irem, e lrem, as quais realizam divises ou clculos de restos em inteiros (int ou long). Cada tipo de opcode no conjunto de instrues JVM tem um mnemnico. No estilo tpico de linguagem de montagem (assembly), streams de bytecodes podem ser representados por seus mnemnicos, seguidos por valores de operando, opcionalmente. Abaixo mostrado um exemplo de stream de bytecodes de um mtodo e mnemnicos. O mtodo utilizado para a exemplificao o mtodo doMathForever(), cujo cdigo fonte Java mostrado abaixo: public static void doMathForever() { int i = 0; for (;;) { i += 1; i *= 2; } } O stream de bytecodes do mtodo doMathForever() pode ser desmontado (disassembled) em mnemnicos como mostrado abaixo. No exemplo, a coluna esquerda mostra o deslocamento (offset) em bytes a partir do incio do stream de bytecodes do mtodo at o incio de cada instruo. A coluna central mostra a instruo e quaisquer operandos em mnemnicos. A coluna direita contm os bytecodes correspondentes aos mnemnicos da instruo. Stream de bytecodes para o mtodo doMathForever(): 03 3b 84 00 01 1a 05 68 3b a7 ff f9 Desmontando o stream de bytecodes para o mtodo doMathForever() em mnemnicos: Offset 0 1 2 5 6 7 8 9 Mnemnico iconst_0 istore_0 iinc 0, 1 iload_0 iconst_2 imul istore_0 goto 2 Bytecode 03 3b 84 00 01 1a 05 68 3b a7 ff f9

A representao de instrues utilizada acima a sada do programa javap do pacote Sun


25

J2SDK, que mostra os mnemnicos de bytecodes de mtodos de qualquer arquivo de classe Java. Os endereos de desvio so determinados como deslocamentos a partir do incio do mtodo. A instruo goto faz com que a JVM salte para a instruo no deslocamento 2. O operando real no stream -7. Para executar essa instruo, a mquina virtual adiciona o operando ao contedo corrente do registrador PC (program counter). O resultado o endereco da instruo iinc no offset 2. Para tornar o mnemnico mais legvel, os operandos para instrues de desvio so mostrados como se a adio j tivesse sido feita. O foco central do conjunto de instrues da JVM a pilha de operando. Valores so usualmente empilhados na pilha de operando antes de serem utilizados. Apesar de a JVM no possuir registradores para armazenar valores arbitrrios, cada mtodo tem um conjunto de variveis locais. O conjunto de instrues trata as variveis locais, de fato, como um conjunto de registradores que so referenciados por ndices. No entanto, diferentemente da instruo iinc, que incrementa uma varivel local diretamente, os valores armazenados em variveis locais devem ser movidos para a pilha de operando antes de serem utilizados. Por exemplo, para dividir uma varivel local por outra, a JVM deve empilhar ambas na pilha de operando, realizar a operao de diviso, e ento armazenar o resultado de volta nas variveis locais. Para mover o valor de um elemento de array ou campo (field) de objeto em uma varivel local, a mquina virtual deve primeiro empilhar o valor na pilha de operando, ento armazen-lo na varivel local. Para colocar em um elemento de array ou campo de objeto um valor armazenado em uma varivel local, a JVM deve seguir o procedimento reverso. Primeiro, ela deve empilhar o valor da varivel local na pilha de operando, e ento desempilh-lo no elemento de array ou campo de objeto na rea heap. Diversos objetivos, alguns conflitantes, guiaram o projeto do conjunto de instrues da JVM. Esses objetivos so basicamente os mesmos que motivaram a arquitetura geral da tecnologia Java: independncia de plataforma, mobilidade de rede e segurana. O objetivo de independncia de plataforma foi a principal influencia no projeto do conjunto de instrues. A abordagem centrada em pilha do conjunto de instrues foi escolhida em contrapartida abordagem centrada em registrador para facilitar implementao eficiente em arquiteturas com poucos registradores ou registradores irregulares, tal como a Intel 80x86. Essa caracterstica do conjunto de instrues, ou seja, a arquitetura centrada em pilha, torna mais fcil a implementao da JVM em uma ampla variedade de arquiteturas hospedeiras. Outra motivao para a arquitetura do conjunto de instrues centrada em pilha que compiladores usualmente utilizam uma arquitetura baseada em pilha para passar uma forma compilada intermediria ou o programa compilado para um ligador/otimizador. O arquivo de classe Java, que em muitos aspectos similar aos arquivos objeto do Unix e Windows emitidos por compiladores C, de fato representa uma forma compilada intermediria de um programa Java. No caso de Java, a mquina virtual atua como ligador dinmico e pode atuar como otimizador. A arquitetura centrada em pilha do conjunto de instrues da mquina virtual Java facilita a otimizao que pode ser realizada em tempo de execuo em conjunto com motores de execuo que realizam compilao JIT ou otimizao adaptativa. O tamanho do arquivo de classe foi tambm um dos principais objetivos de projeto, tendo em vista a possibilidade de facilitar e tornar mais rpida a transmisso de arquivos de classe atravs de redes de computadores. Nos bytecodes armazenados em arquivos de classe, todas as instrues, com exceo de duas que lidam com tabelas de salto, so alinhadas em fronteiras de byte. O nmero total de opcodes demanda apenas um byte para a representao de todos eles. Essa estratgia de projeto favorece a compactao do arquivo de classe, mas proporciona impacto de performance quando o programa executado. Em algumas implementaes JVM,


26

especialmente aquelas que executam bytecodes em chips, o opcode de byte nico pode obstruir certas otimizaes que poderiam aprimorar a performance. Alm disso, melhor performance poderia ser possvel em algumas implementaes se os streams de bytecodes fossem alinhados por palavras ao invs de bytes. Uma implementao poderia sempre realinhar streams de bytecodes, ou traduzir opcodes em uma forma mais eficiente conforme classes so carregadas. Bytecodes so alinhados por bytes nos arquivos de classe e na especificao da rea de mtodo e do motor de execuo. Implementaes concretas podem armazenar os streams de bytecodes carregados da forma que desejarem. Outro objetivo que guiou o projeto da arquitetura do conjunto de instrues foi a habilidade de fazer verificao de bytecode, especialmente todo o stream de uma vez por um analisador de fluxo de dados. A capacidade de verificao necessria como parte do framework de segurana de Java. A habilidade de utilizar um analisador de fluxo de dados nos bytecodes quando eles so carregados, ao invs de verificar cada instruo conforme ela executada, possibilita melhor velocidade de execuo. Uma das formas na qual esse objetivo de projeto se manifesta no conjunto de instrues que os opcodes indicam o tipo com o qual eles operam. Por exemplo, ao invs de ter uma instruo que desempilha uma palavra da pilha de operando e armazena a palavra em uma varivel local, a arquitetura do conjunto de instrues tem duas. Uma instruo, istore, desempilha e armazena um inteiro. A outra, fstore, desempilha e armazena um pontoflutuante. Ambas, portanto, realizam a mesma operao. A distino entre desempilhar e armazenar um int e um float importante somente para o processo de verificao. Para muitas instrues, a mquina virtual necessita saber os tipos que esto sendo operados para saber como realizar a operao. Por exemplo, a JVM suporta dois modos de adio de duas palavras, gerando como resultado uma palavra. Uma adio trata as palavras como inteiros, e a outra, como pontos-flutuantes. A diferena entre essas duas instrues facilita a verificao, conforme indicado anteriormente, mas tambm informa mquina virtual se ela deve realizar aritmtica inteira ou de ponto-flutuante, que envolvem operaes diferenciadas. Poucas instrues operam sobre qualquer tipo. A instruo dup, por exemplo, duplica a palavra do topo de uma pilha indiferentemente de seu tipo. Algumas instrues, tais como goto, no operam com valores tipados. A maioria das instrues, no entanto, operam sobre valores de tipos especficos. Os mnemnicos para muitas dessas instrues tipadas indica seus tipos por um prefixo de um caractere que inicia o mnemnico. A tabela abaixo mostra os prefixos para os diversos tipos. Algumas poucas instrues, tais como, arraylength e instanceof, no incluem um prefixo, pois seus tipos so bvios. O opcode arraylength requer uma referncia de array, e instanceof requer uma referncia de objeto. Tipo byte short int long char float double reference Prefixo b s i l c f d a Exemplo de Instruo baload saload iaload laload caload faload daload aaload

Valores na pilha de operando devem ser utilizados de uma maneira apropriada aos seus tipos. ilegal, por exemplo: desempilhar quarto inteiros, e ento adicion-los como se fossem dois longs.


27

ilegal empilhar um valor do tipo float na pilha de operando a partir das variveis locais, e ento armazen-lo como um inteiro em um array na heap. ilegal empilhar um valor double a partir de um campo de objeto na heap, e ento armazenar a palavra mais significativa de suas duas palavras em variveis locais como um valor de tipo reference. As regras rgidas de tipagem que so aplicadas por compiladores Java devem ser aplicadas tambm por implementaes JVM. Para manter o conjunto de instrues com um tamanho que possibilitasse a representao de todos os opcodes com apenas um byte, nem todas as operaes so suportadas em todos os tipos. Muitas operaes no so suportadas para os tipos byte, short e char, que so convertidos para int quando movidos da rea de mtodo ou da heap para a pilha. Eles so operados como inteiros, e ento convertidos novamente para o tipo correto antes de serem armazenados novamente na heap ou na rea de mtodo.

4.1. Instrues Load/StoreAs instrues load e store transferem valores entre as variveis locais e a pilha de operando de um quadro JVM. A seguir so listadas as instrues load e store: carrega uma varivel local na pilha de operando: iload, iload_, lload, lload_, fload, fload_, dload, dload_, aload, aload_; armazena um valor da pilha em uma varivel: istore, istore_, lstore, lstore_, fstore, fstore_, dstore, dstore_, astore, astore_; armazena uma constante na pilha: bipush, sipush, ldc, ldc_w, ldc2_w, aconst_null, iconst_m1, iconst_, lconst_, fconst_, dconst_; obtm acesso a mais variveis locais utilizando um ndice mais amplo, ou a um operando imediato maior: wide.

Mnemnicos com sufixos denotam famlias de instrues, com membros, por exemplo, iload_0, iload_1, iload_2, e iload_3 no caso da instruo iload_. Tais famlias de instrues so especializaes de uma instruo genrica adicional (iload) que carrega um operando. Para as instrues especializadas, o operando implcito e no precisa ser armazenado ou buscado (fetch). De qualquer forma a semntica a mesma, por exemplo, iload_0 significa o mesmo que iload com o operando 0. A letra x entre especifica o tipo do operando implcito: , inteiro no negativo; , inteiro; , long; , float; , double.

4.2. Instrues Aritmticas/LgicasAs instrues aritmticas computam um resultado que uma funo de dois valores na pilha de operando, empilhando o resultado de volta na pilha. Existem dois tipos: as que operam com valores inteiros e as que operam com valores de ponto-flutuante. Dentro de cada um dos tipos de instrues aritmticas, as instrues so especializadas para os tipos numricos da JVM. No h suporte direto para aritmtica com valores dos tipos byte, short, e char, bem como com valores do tipo boolean suportados pela linguagem de programao Java. As operaes com esses tipos so manipuladas por instrues que operam sobre o tipo int. Instrues com inteiros e pontos-flutuantes tambm diferem em seus comportamentos com relao a overflow e diviso por zero. As instrues aritmticas e lgicas JVM so as seguintes:


28

adio: iadd, ladd, fadd, dadd; subtrao: isub, lsub, fsub, dsub; multiplicao: imul, lmul, fmul, dmul; diviso: idiv, ldiv, fdiv, ddiv; resto: irem, lrem, frem, drem; negao: ineg, lneg, fneg, dneg; deslocamento: ishl, ishr, iushr, lshl, lshr, lushr; OR bit-a-bit: ior, lor; AND bit-a-bit: iand, land; XOR bit-a-bit: ixor, lxor; incremento de varivel local: iinc; comparao: dcmpg, dcmpl, fcmpg, fcmpl, lcmp.

4.3. Instrues de Converso de TiposPermitem converses entre tipos numricos JVM. Essas instrues podem ser utilizadas para implementar converses explcitas no cdigo do usurio ou para suavizar a falta de ortogonalidade no conjunto de instrues JVM. A mquina virtual suporta diretamente as seguintes converses de ampliao numrica, listadas juntamente com as instrues correspondentes: int para long, float, ou double: i2l, i2f, i2d; long para float ou double: l2f, l2d; float para double: f2d.

Converses de ampliao numrica no provocam perda de informao sobre a magnitude do valor numrico. Entretanto, dependendo dos tipos de origem e destino, pode ocorrer perda de preciso. Apesar desse fato, converses de ampliao numrica nunca fazem com que a JVM dispare excees. A JVM tambm suporta diretamente as seguintes converses de contrao numrica, listadas juntamente com as instrues correspondentes: int para byte, short, ou char: i2b, i2s, i2c; long para int: l2i; float para int ou long: f2i, f2l; double para int, long, ou float: d2i, d2l, d2f.

Converses de contrao numrica podem resultar em um valor de sinal diferente, ordem de magnitude diferente, ou ambos. Alm disso, pode haver perda de preciso. Apesar de poder ocorrer overflow, underflow e perda de preciso, converses de contrao numrica nunca provocam o disparo de excees por parte da JVM.

4.4. Instrues de ObjetosApesar de instncias de classes e arrays serem objetos na linguagem Java, a JVM cria e manipula instncias de classes e arrays utilizando instrues diferentes:


29

criao de uma nova instncia de classe: new; criao de um novo array: newarray, anewarray, multianewarray; acesso a campos de classes (tambm chamados de campos estticos ou variveis de classes) e campos de instncias de classes (tambm chamados de campos no-estticos ou variveis de instncias): getfield, putfield, getstatic, putstatic; carga de um componente de array na pilha de operando: baload, caload, saload, iaload, laload, faload, daload, aaload; armazenamento de um valor da pilha de operando como um componente de array: bastore, castore, sastore, iastore, lastore, fastore, dastore, aastore; obteno do tamanho de um array: arraylength; verificao de propriedades de instncias de classes e arrays: instanceof, checkcast.

4.5. Instrues de PilhaDiversas instrues so providas para a manipulao direta da pilha de operandos: pop, pop2, dup, dup2, dup_x1, dup2_x1, dup_x2, dup2_x2, swap.

4.6. Instrues de DesvioFazem com que a JVM condicionalmente ou incondicionalmente continue a execuo com uma instruo que no a seguinte instruo de desvio. So elas: desvio condicional: ifeq, iflt, ifle, ifne, ifgt, ifge, ifnull, ifnonnull, if_icmpeq, if_icmpne, if_icmplt, if_icmpgt, if_icmple, if_icmpge, if_acmpeq, if_acmpne; desvio condicional composto: tableswitch, lookupswitch; desvio incondicional: goto, goto_w, jsr, jsr_w, ret.

A mquina virtual possui instrues distintas que condicionalmente desviam em comparaes com dados de tipo int e reference. Ela tambm possui instrues de desvio condicional distintas que testam para a referncia nula, e, portanto no requerido especificar um valor concreto para null. Desvios condicionais com comparaes entre tipos boolean, byte, char, e short so realizadas utilizando instrues int. Desvios condicionais com comparaes entre tipos long, float, ou double utilizam primeiro uma instruo que compara os dados e produz um resultado inteiro da comparao. Uma instruo int subseqente testa o resultado e realiza o desvio. Devido nfase em comparao inteira, a JVM prov um rico complemento de instrues de desvio para o tipo int. Todas as instrues de desvio int realizam comparaes sinalizadas.

4.7. Instrues de MtodosAs seguintes instrues invocam mtodos: invocao de mtodo de objeto: invokevirtual; invocao de mtodo de interface: invokeinterface; invocao de mtodo de objeto que requer tratamento especial (mtodos de inicializao de instncias, mtodos privados e mtodos de super-classes): invokespecial; invocao de mtodo esttico de classe: invokestatic.


30

As instrues de retorno de mtodo so distinguidas pelo tipo de dado de retorno: retorna valores de tipo boolean, byte, char, short, ou int: ireturn; retorna valores de tipo long: lreturn; retorna valores de tipo float: freturn; retorna valores de tipo double: dreturn; retorna valores de tipo reference: areturn.

4.8. Instrues de ExceesUma exceo disparada programaticamente utilizando a instruo athrow. Alm disso, excees podem tambm ser disparadas por vrias instrues JVM se elas detectarem uma condio anormal. A implementao da clusula finally para tratamento de excees utiliza as instrues jsr, jsr_w, e ret.

4.9. Instrues de SincronizaoA JVM suporta a sincronizao de mtodos e seqncias de instrues dentro de um mtodo utilizando um construtor nico de sincronizao, o monitor. A JVM prov as instrues monitorenter e monitorexit para suportar tais construtores. A sincronizao de nvel de mtodo manipulada como parte de invocao e retorno de mtodo. J a sincronizao a nvel de seqncias de instrues tipicamente empregada para codificar os blocos de sincronizao da linguagem Java. A implementao apropriada de blocos de sincronizao requer a cooperao de um compilador para a JVM. O compilador deve garantir que em qualquer concluso de invocao de mtodo uma instruo monitorexit ter sido executada para cada instruo monitorenter executada a partir da invocao do mtodo.

5. Conjunto de Instrues CLRSegundo Meijer (2001) e Microsoft (2001), MSIL um conjunto de instrues baseado em pilha, assim como bytecodes Java. Ele foi projetado com o objetivo de ser facilmente gerado a partir de cdigo fonte por compiladores e outras ferramentas. Diversos tipos de instrues so providos, incluindo instrues para operaes aritmticas e lgicas, controle de fluxo, acesso direto memria, tratamento de exceo e invocao de mtodo. H tambm instrues para a implementao de construes do paradigma orientado a objetos, tais como, chamada de mtodo virtual, acesso a campo, acesso a array, e alocao e inicializao de objeto. O projeto da MSIL permite que programas no typesafe possam ser expressos, tendo em vista que isso essencial para suportar algumas linguagens de programao ainda comumente utilizadas. Ao mesmo tempo, seguindo um conjunto de regras simples, possvel gerar programas MSIL typesafe.

5.1. Tipos de Dados SuportadosOs seguintes tipos de dados podem ser manipulados utilizando o conjunto de instrues MSIL, e, portanto so diretamente suportados pela CLR:


31

Tipos I1 U1 I2 U2 I4 U4 I8 U8 R4 R8 I U R4Result R8Result RPrecise O &

Descrio Valor sinalizado em complemento a dois de 8 bits Valor binrio no-sinalizado de 8 bits Valor sinalizado em complemento a dois de 16 bits Valor binrio no-sinalizado de 16 bits Valor sinalizado em complemento a dois de 32 bits Valor binrio no-sinalizado de 32 bits Valor sinalizado em complemento a dois de 64 bits Valor binrio no-sinalizado de 64 bits Valor em ponto-flutuante IEEE 754 de 32 bits Valor em ponto-flutuante IEEE 754 de 64 bits Valor sinalizado em complemento a dois de tamanho natural Valor no-sinalizado de tamanho natural, tambm unmanaged pointer Tamanho natural para resultado de uma computao com ponto-flutuante IEEE 754 de 32 bits Tamanho natural para resultado de uma computao com ponto-flutuante IEEE 754 de 64 bits Valor em ponto-flutuante de preciso mxima Object reference de tamanho natural para memria gerenciada Managed pointer de tamanho natural (pode apontar para memria gerenciada)

Os tipos de tamanho natural (ou genricos) so um mecanismo na CLR para adiar a escolha de um tamanho de valor. Esses tipos de dados existem como tipos MSIL. Mas, quando so compilados para cdigo nativo, o compilador JIT mapeia cada um para o tamanho natural para o processador especfico. Por exemplo, o tipo de dados I mapeado para I4 em um processador Pentium, e I8 em um processador IA64. Portanto, a escolha de tamanho postergada at a compilao JIT, quando a CLR foi inicializada e a arquitetura alvo conhecida, o que implica que offsets de campo (field) e quadro de pilha (stack frame) tambm no so conhecidos em tempo de compilao. Para linguagens como Visual Basic, onde offsets de campos no so computados previamente, isso no um problema. Em linguagens como C ou C++, uma suposio conservadora de que eles ocupam 8 bytes algumas vezes aceitvel. Os tipos genricos da CLR foram projetados para evitar partes desse problema. O modelo CLR utiliza uma pilha de avaliao, e diponibiliza instrues load/store para copiar valores da memria na pilha e da pilha para a memria. O completo conjunto de tipos de dados da tabela acima pode ser representado na memria da CLR. Entretanto, a CLR suporta apenas um sub-conjunto desses tipos em suas operaes sobre valores na pilha de avaliao (I4, I8, I). Alm disso, a CLR suporta um tipo de dado interno (F) para representar valores em pontoflutuante na pilha. O tipo F pode ser imaginado como comeando no tamanho de valores carregados da memria e ento espandido quando combinado com valores de alta-preciso. Valores pequenos (I1, I2, U1, U2) so ampliados quando carregados da memria para a pilha e contrados quando armazenados da pilha na memria. A CLR reflete um modelo computacional que assume que clulas de memria possuem larguras de 1, 2, 4, ou 8 bytes, mas registradores e localizaes de pilha so de 4 ou 8 bytes. O suporte para valores pequenos na CLR :


32

instrues load/store para/da memria: ldelem, ldind, stind, stelem; instrues aritmticas com deteco de overflow: add.ovf, mul.ovf, sub.ovf; instrues de converso de dados: conv, conv.ovf; instrues para carga de constantes: ldc; instrues de criao de array: newarr.

Os tipos inteiros sinalizados (I1, I2, I4, I8, e I) e no-sinalizados (U1, U2, U4, U8, e U) diferem apenas na forma como os bits do inteiro so interpretados. Para operaes onde um inteiro no sinalizado tratado diferentemente de um sinalizado, como, por exemplo, comparaes e aritmticas com overflow, existem instrues separadas para tratar um inteiro como no sinalizado, por exemplo, cgt.un e add.ovf.u. Essa arquitetura de conjunto de instrues simplifica compiladores JIT de MSIL ao possibilitar que eles tratem um nmero menor de tipos de dados internamente. Instrues MSIL no especificam os tipos de seus operandos. Ao invs disso, a CLR mantm tracks de tipos de operandos e o compilador JIT gera o cdigo nativo apropriado, conforme indicado abaixo. Por exemplo, uma instruo add ir adicionar ints ou floats da pilha.

5.2. Tipos NumricosA maior parte das instrues MSIL que manipulam nmeros obtm seus operandos da pilha de avaliao, e essas entradas tm um tipo associado que conhecido pelo compilador JIT. Como resultado, diferentemente das instrues JVM, uma nica operao, tal como adio, pode ter entradas de qualquer tipo de dado numrico, apesar de nem todas as instrues poderem manipular todas as combinaes de tipos de operandos. As categories de instrues so listadas a seguir: Numeric: instrues que manipulam nmeros inteiros e em ponto-flutuante, e consideram inteiros como sinalizados. Aritmtica, desvio condicional, e instrues de comparao fazem parte dessa categoria; Integer: instrues que manipulam somente nmeros inteiros. Operaes de bit e diviso/resto de inteiros no sinalizados fazem parte dessa categoria; Floating point: instrues que manipulam somente nmeros em ponto-flutuante; Specific: instrues que manipulam nmeros inteiros e/ou em ponto-flutuante, mas possuem variantes que manipulam particularmente inteiros no sinalizados e de tamanhos diferentes. Operaes inteiras com deteco de overflow, instrues de converso de dados, e operaes que transferem dados entre a pilha de avaliao e outras partes de memria esto nessa categoria; Unsigned/unordered: h instrues de desvio e comparao especiais que tratam inteiros como no sinalizados, e consideram nmeros em ponto-flutuante no ordenados especialmente; Load constant: as instrues load constant podem ser utilizadas para carregar constantes inteiras ou reais.

5.3. Tipos PonteirosA CLR tem a habilidade de seguir ponteiros para objetos e coletar objetos que no so mais alcanveis (gerenciamento de memria por garbage collection). Para que isso funcione corretamente, ponteiros para objetos devem ser utilizados. Os tipos de dados O (object reference) e & (managed pointer) provem esse suporte.


33

A utilizao de referncias a objetos fortemente restringida na MSIL. Elas so utilizadas quase que exclusivamente com as instrues de sistema de objeto virtual virtual object system, que so instrues especialmente projetadas para manipular objetos. Entretanto, algumas poucas instrues bsicas da MSIL podem manipular referncias a objetos. Em particular, referncias a objetos podem ser: carregadas da pilha de avaliao para serem passadas como argumentos para mtodos: ldloc, ldarg; armazenadas, a partir da pilha, em suas home locations: stloc, starg; duplicadas ou desempilhadas da pilha de avaliao: dup, pop; comparadas entre si: beq, beq.s, bne, bne.s, ceq; carregadas de / armazenadas em memria no gerenciada, apenas em cdigo de tipo no gerenciado: ldind.ref, stind.ref; criao de uma referncia nula: ldnull; retornada como valor: ret. Ponteiros gerenciados possuem diversas operaes bsicas adiconais: adio e subtrao de inteiros, em unidades de bytes, retornando um ponteiro gerenciado: add, add.ovf.u, sub, sub.ovf.u; subtrao de dois ponteiros gerenciados para elementos do mesmo array, retornando o nmero de bytes entre eles: sub, sub.ovf.u; comparao no sinalizada e salto condiconal baseado em dois ponteiros gerenciados: bge.un, bge.un.s, bgt.un, bgt.un.s, ble.un, ble.un.s, blt.un, blt.un.s, cgt.un, clt.un.

5.4. Dados AgregadosA CLR suporta dados agregados, isto , itens de dados que possuem sub-componentes (arrays, estruturas, objetos), mas que so passados por valor; os sub-componentes podem incluir referncias para memria gerenciada. Dados agregados so representados utilizando um tipo de valor, que pode ser instanciado de duas maneiras: boxed: como um objeto, carregando informao de tipo completa em tempo de execuo, e tipicamente sendo alocado na heap pelo gerenciador de memria; unboxed: como uma instncia de tipo de valor, que no carrega informao de tipo em tempo de execuo, e que nunca alocada diretamente na heap, podendo ser armazenada nas variveis locais ou no array de argumentos de entrada.

5.4.1. Homes para Valores A casa (home) de um valor onde o valor armazenado para possvel reuso. A CLR suporta diretamente as seguintes home locations: um argumento de entrada, uma varivel local de um mtodo, um campo de instncia de um objeto ou tipo de valor, um campo esttico de uma classe, interface ou mdulo, e um elemento de array. Para cada home location existe meio para computer em tempo de execuo o endereo da home location, e meio para determinar em tempo de compilao JIT o tipo de uma home location, conforme mostrado na tabela a seguir:


34

Home location Argumento Varivel Local Campo Esttico Elemento de Array

Computao de endereo ldarga para argumentos por valor. ldarg para argumentos por referncia. ldloca para locais por valor. ldloc para locais por referncia. ldflda ldslfda ldelema

Determinao de tipo Assinatura do mtodo. Assinaturas locais no cabealho do mtodo. Tipo do campo na classe, interface ou mdulo. Tipo do campo na classe, interface ou mdulo. Tipo de elemento do array.

Alm das homes, valores built-in podem existir em duas maneiras adicionais, isto , sem homes: como valores constantes: embarcados no stream de instrues MSIL utilizando instrues ldc.*; como um valor intermedirio na pilha de avaliao, quando retornado por um mtodo ou instruo MSIL.

5.4.2. Operaes em Instncias de Tipo de Valor Instncias de tipo de valor podem ser criadas, passadas como argumentos, retornadas como valores, e armazenadas ou carregadas de variveis locais, campos, e elementos de array. Assim como classes, tipos de valor podem ter membros (mtodos e campos) estticos e noestticos. Mas, como eles no carregam nenhuma informao de tipo em tempo de execuo, eles no podem ser substitutos para itens de tipo Object, de forma que, eles de fato atuam como tipos primitivos. Existem trs opes para inicializar a home location de uma instncia: zerar a home location, carregando seu endereo e utilizando a instruo initobj; chamar um construtor definido pelo usurio, carregando o endereo da home location e ento chamando o construtor diretamente; copiar uma instncia existente na home location. Existem duas opes para carregar uma instncia na pilha de avaliao: carregar o valor da home que possui o tipo apropriado diretamente, utilizando instrues ldarg, ldloc, ldfld, ou ldsfld; computar o endereo do tipo, e ento utilizar a instruo ldobj. Existem duas opes para armazenar uma instncia da pilha de avaliao: armazenar o valor na home do tipo apropriado diretamente, utilizando instrues starg, stloc, stfld, ou stsfld; computar o endereo do tipo, e ento utilizar a instruo stobj.


35

Instrues para passar e retornar tipos de valores: para passar um tipo de valor por valor, carrega-o na pilha como qualquer outro argumento, utilizando instrues ldloc, ldarg, etc., ou chama um mtodo que retorna um tipo de valor. Para acessar um parmetro de tipo de valor que foi passado por valor utiliza-se a instruo ldarga para computar seu endereo ou ldarg para carregar o valor na pilha de avaliao; para passar um tipo de valor por referncia, carrega seu endereo normalmente. Para acessar um parmetro de tipo de valor que foi passado por referncia utiliza-se a instruo ldarg para computar seu endereo do argumento, e ento a instruo ldobj para carreg-lo na pilha de avaliao; para retornar um tipo de valor, carrega o valor na pilha de avaliao e ento emite uma instruo ret.

5.5. Controle de FluxoA arquitetura do conjunto de instrues MSIL prov um rico conjunto de instrues para alterar o fluxo de controle normal de uma instruo MSIL para a prxima: instrues de desvio condicional e incondicional para utilizao dentro de mtodos (cuidando para que a transferncia no cruze a fronteira de uma regio protegida); instrues de chamada de mtodo para computar novos argumentos; prefixo tail call para indicar que um mtodo deveria abdicar de seu quadro de pilha antes de executar uma chamada de mtodo; instrues para retornar de um mtodo, despachando um valor se necessrio; instrues de salto de mtodo para transferir os argumentos do mtodo corrente para um mtodo destinatrio conhecido ou computado; instrues relacionadas a exceo, que incluem instrues para iniciar uma exceo, transferir controle para fora de uma regio protegida, e concluir um filtro (filter), clusula catch ou clusula finally.

Enquanto a CLR suporta transferncias arbitrrias de controle dentro de um mtodo, h diversas restries que devem ser observadas, e que so testadas pelo verificador: no permitido entrar em clusulas catch e finally, exceto atravs do mecanismo de tratamento de exceo; sair de uma regio protegida permitido somente atravs de instrues de tratamento de exceo (leave, end.filter, end.catch, ou end.finally); a pilha de avaliao deve estar vazia aps o valor de retorno ser desempilhado por uma instruo ret; todos os slots na pilha devem ter o mesmo tipo de dados em todos os pontos dentro do corpo de um mtodo; para que compiladores JIT possam eficientemente rastrear os tipos de dados armazenados na pilha, a pilha deve estar vazia na instruo seguinte a uma instruo de transferncia de controle incondicional (br, br.s, ret, jmp, jmpi, throw, end.filter, end.catch, ou end.finally). A pilha poder no estar vazia nesse ponto somente se em algum local anterior dentro do mtodo existir alguma instruo de desvio para a localizao dessa instruo; todos os caminhos de um mtodo devem terminar com um das seguintes instrues: ret, throw, jmp, jmpi, ou (tail. seguida por call, calli, ou callvirt).


36

5.6. Invocao de MtodosTodas as invocaes de mtodos inicializam as reas de estado de mtodo da seguinte forma: o array de argumentos de entrada preenchido pelo invocador com os valores desejados; o array de variveis locais sempre possui null para tipos Object e para campos de tipos de valores que contm objetos. Alm disso, se o flag de inicializao zerada estiver selecionado no cabealho de mtodo, ento ele inicializado com 0 para todos os tipos inteiros e 0.0 para todos os tipos pontos-flutuantes; se o flag de inicializao zerada estiver selecionado no cabealho de mtodo, ento o local memory pool inicializ

Arquitetura de Maquinas Virtuais - UNICAMP

Documents

Transcript of Arquitetura de Maquinas Virtuais - UNICAMP