Você está na página 1de 7

JAVA VIRTUAL MACHINE (JVM)

Por Leandro Baptista, Marlon Palangani e Tiago Deoldoto, 11 de Abril de 2009

A linguagem de programao Java proporciona o desenvolvimento aplicaes que podem ser executadas em diversos tipos de plataformas e Sistemas Operacionais. Tudo isso tornou-se possvel graas a Mquina Virtual Java. Nesse artigo voc encontrar informaes a respeito do funcionamento, arquitetura e diversas vantagens que essa ferramenta proporciona, tanto para usurios simples como para desenvolvedores de sistemas. O QUE JAVA VIRTUAL MACHINE?
A JVM (do ingls Java Virtual Machine) um programa que carrega e executa os aplicativos Java, convertendo os bytecodes em cdigo executvel de mquina, apenas um aspecto do software Java envolvido na interao com a Web. A JVM reponsvel pelo gerenciamento dos aplicativos, medida que so executados. Graas maquina virtual Java, os programas escritos em Java podem funcionar em qualquer plataforma de hardware e software que possua uma verso da JVM, tornando assim essas aplicaes independentes da plataforma onde funcionam. A arquitetura de JVM permite um controle muito fino sobre as liberadas para o cdigo que esta rodando na VM. Isso permite a execuo de cdigo confivel de fontes remotas, um modelo usado pelos applets. Os applets rodam dentro de uma VM incorporada ao browser do usurio, exectando cdigo baixado de um servidor HTTP remoto. O cdigo remoto roda em uma sandbox, que protege o usurio de cdigos maliciosos. O autor do applet pode aplicarum certificado para assinar digitalmente o applet como seguro, dando a ele permisso de sair do sandbox e acessar livremente a mquina onde esta rodando. Podemos dizer tambm que a maquina virtual Java uma mquina de computao abstrata. Como uma mquina de computao real, tem um jogo de instruo e manipula vrias reas de memria no tempo de execuo. razoavelmente comum executar uma linguagem de programao usando mquina virtual. A mquina virtual mais conhecida, pode ser a mquina do P-Cdigo de UCSD Pascal. A primeira execuo do prottipo da mquina virtual de Java, emulou o jogo de instrues em um software hospedado por um dispositivo handheld que se assemelhasse a um assistente de Digitas pessoais contemporneo (PDA). As execues atuais da mquina virtual de Java, emulam em anfitries de Win32 e de solaris em umas maneiras muito mais sofisticadas. Com a linguagem de programao Java, podemos, por exemplo, criar um aplicativo que rode tanto no Linux quanto no Windows, como foi dito acima. Mas no se limita a esses sistemas operacionais, sendo possivel desenvolver para uma infinidade de plataformas, para isso basta que elas tenham uma JVM. Voc ja deve ter usado Java antes e no sabe. Por exemplo, em uma fila de banco, onde voc fica jogando em seu telefone celular enquanto aguarda sua vez. Os aplicativos feitos em Java esto presentes em uma infinidade de dispositivos, desde relgios at mainframes, relembrando novamente que, tudo isso graas a Mquina Virtual Machine.

ENTENDENDO MELHOR O FUNCIONAMENTO DA JVM


Vamos tentar entender melhor como a JVM funciona. Quando se faz um programa em Java e o compila, se tudo estiver certo, o compilador gera bytecodes desse programa. Bytecode uma espcie de codificao que traduz tudo o que foi escrito no programa para um formato que a JVM entenda e seja capaz de executar,

assim sendo capaz de rodar em qualquer sistema operacional que tenha a JVM. Isso ocorre porque no existe bytecodes diferentes, isto , os bytecodes dos programas em Java compilados no Windows so constituidos da mesma forma que bytecodes gerados se a compilao fosse feita em Mac OS. De certo que, podem haver algumas diferenas, que dependem da implementao da JVM e claro, do compilador. Quando um cdigo em Java compilado, um arquivo com a extenso .class gerado. Esse tipo de arquivo o bytecode, ento quando o programa Hello.java for compilado, um arquivo chamado Hello.class dever ser executado. A imagem a seguir ilustra esse processo.

Construir uma JVM no fcil, ela envolve uma srie de conceitos complexos, como instrues equivalentes a de processadores, controle de acesso memria, registradores, etc. Isso pode at parecer estranho, mas necessrio entender que as JVMs atuam, de fato, como uma mquina. Muitos usurios relutam em instalar a mquina virtual Java, dizem que gastam memria, que ocupa muito espao desnecessrio, mas a verdade que bem configurado, ela se torna leve como uma pluma. Uma curiosidade que podemos citar, que, um ponto que merece destaque na arquitetura desenvolvida pela Sun para a plataforma Java o uso da mquina virtual em troca de um cdigo compilado especifico para um computador. Diversos outros modelos necessitam que um determinado programa seja compilado para cada tipo de computador em que ser utilizado, o que pode ser proibitivo para alcanar uma larga escala.

ARQUITETURA DA MAQUINA VIRTUAL JAVA


Principais subsistemas da mquina virtual Java (JVM): - Carregador de classe (class loader), carregar classes e interfaces a partir de nomes completamente qualificados. - Mquina de execuo (execution engine), executa instrues das classes carregadas. - reas de dados de execuo (runtime data areas), organizada em rea de mtodos (method area), rea de memria dinmica (help), pilhas (stacks), contadores de programas (program counters ou pc) e pilhas dos mtodos nativos (native methods stacks). A especificao destas reas varia de implementao para implementao para permitir que caractersticas especificas de uma dada arquitetura possam ser exploradas. Cada instncia da mquina virtual tem uma rea de mtodos e uma heap que so compartilhadas por todas as threads sendo executadas na mquina virtual. Cada thread cria um registro de ativao (frame) na pilha

da thread contendo o estado do mtodo, o que inclui parmetros, variveis locais, valor de retorno e clculos intermedirios. - Interface de mtodos nativos (native method interface). A JVM uma maquina de pilha. As instrues da JVM utilizam a pilha para armazenar resultados intermedirios, ao invs de utilizar registradores como feito em arquiteturas concretas. Isto permite a definio de um conjunto simples de instrues que facilmente implementado em diferentes arquiteturas. Na JVM existem tipos primitivos, como byte, short, int, long, float e Double e referencias a objetos. O tamanho de uma palavra (Word) na JVM varia de implementao para implementao da JVM e deve ser grande o suficiente para armazenar um byte, int, float, uma referencia a um objeto ou um return address, este ultimo utilizado para implementar clusulas finally em Java. Duas palavras devem ser capazes de armazenar os tipos long e Double.

OTIMIZANDO O USO DA MEMRIA EM APLICAES JAVA Em Java, diferente de outras linguagens como C e C++, o programador no precisa desalocar memria, usando funes como free e delete. Java possui um coletor de lixo, uma thread de baixa prioridade que executa junto com a Java Virtual Machine. Sua funo gerenciar a utilizao de memria, procuranado reas de memria que no estejam mais em uso para realizar a liberao das mesmas. A execuo do coletor de lixo transparente para o programador, porm, podemos em algumas situaes desejar usar artifcios para otimizar o uso da memria pela JVM.

FUNCIONAMENTO DO COLETOR DE LIXO


O coletor de lixo libera a memria mantida por um objeto se no houver mais nenhuma referncia para ele. Dependendo do algoritmo da coleta de lixo usado pela mquina virtual Java no qual o cdigo est sendo executado, nem todo objeto no referenciado ser desalocado pelo coletor de lixo. Um objeto mais antigo, de longa durao, menos provvel de estar no referenciado do que um objeto novo, de modo que um algoritmo comum para coleta de lixo analisar os objetos mais antigos com menos freqncia do que os objetos mais novos. Podemos ter uma mtrica da eficincia da implementao do coletor de lixo utilizado pela sua JVM com o cdigo abaixo: Runtime rt = Runtime.getRuntime(); long mem = rt.freeMemory(); System.out.println("Memria Livre: " + mem); // ... algum cdigo System.gc(); // ... mem = rt.freeMemory(); System.out.println("Memria Livre: " + mem);

O cdigo acima obtm o ambiente de execuo com o mtodo esttico getRuntime() da classe Runtime. O mtodo freeMemory() retorna a memria disponvel no ambiente runtime. A linha System.gc() faz a chamada explcita do coletor de lixo. Em algumas implementaes da JVM, o coletor de lixo pode ser ativado atravs da chamada ao mtodo System.gc(), embora a especificao no garanta isso. De todo modo, a

maior parte das JVMs fazem a chamada do coletor implicitamente quando a memria est baixa ou quando a CPU est inativa por um certo perodo de tempo. Problemas com a utilizao de memria podem surgir quando os objetos contm variveis de instncia que so iniciadas no construtor, ocupam um grande quantidade de memria e no so mais utilizadas no restante da aplicao. Isso pode degradar o desempenho de um cdigo.

LIBERANDO UM OBJETO
Uma maneira de tornar um objeto candidato a ser retirado da memria pelo coletor de lixo atribuindo o valor null sua referncia. Com isso, o objeto torna-se no referenciado e pode ser retirado da memria pelo coletor de lixo. O programa abaixo ilustra essa tcnica: import java.util.*; class GarbageExample { private static Vector vetor; public static void main(String args) { vetor = new Vector(); for (int a=0; a < 500; a++) vetor.addElement(new StringBuffer("teste")); Runtime rt = Runtime.getRuntime(); System.out.println("Memria Livre: " + vetor = null; System.gc(); System.out.println("Memria Livre: " + rt.freeMemory()); } } O cdigo acima aloca 500 objetos StringBuffer e os coloca dentro de um Vector. O objeto da classe Vector referenciado pela varivel vetor. Quando se atribui o valor null para a varivel vetor o contedo do objeto Vector (500 objetos StringBuffer) no possui mais referncia na aplicao. A chamada explcita ao coletor de lixo faz a limpeza desse objeto. O programa exibe a quantidade de memria livre antes e depois da execuo do coletor de lixo. Essa tcnica pode solucionar o problema de manter grandes quantidades de memria desnecessrias. Para usar o mnimo de memria possvel, os objetos que precisem existir durante um tempo maior devem ser os menores possveis. Do outro lado, os grandes objetos devero existir pelo menor tempo possvel. Essa tcnica pode ajudar, em alguns casos, somente o desempenho das aplicaes Java que executam na mesma JVM e no necessariamente de outros processos rodando no sistema. Isso porque muitos algoritmos de gerenciamento de heap alocam antecipadamente uma parte da memria para ser usada pelo seu cdigo. rt.freeMemory());

Ou seja, voc libera a memria da mquina virtual Java, o que no afetar outras aplicaes no-Java, pelo fato da JVM pre-alocar o heap que ela precisa. A qualquer momento pode-se solicitar a execuo do coletor de lixo (sem garantias de execuo), chamando o mtodo System.gc(). Porm, necessrio analisar o impacto de desempenho na sua aplicao. Muitos algoritmos de coleta de lixo suspendem todas as outros threads antes de entrar em execuo. Isso garante que, quando o coletor de lixo for executado, ele ter acesso completo memria no heap e poder realizar suas tarefas com segurana, sem que seja interrompido por outra thread. Quando o coletor de lixo termina seu trabalho, todas as threads que ele suspendeu so retomados. O coletor de lixo de Java executado com uma grande freqncia, sua chamada explcita dificilmente necessria. Porm, em alguns casos pode tornar-se conveniente. recomendado evitar a chamada ao mtodo System.gc() pelo bloqueio que provoca. recomendado tambm nunca fazer essa chamada explcita dentro de loops.

O MTODO FINALIZE()
O programador pode definir o mtodo finalize() que ser chamado sempre antes do objeto ser retirado da memria pelo coletor de lixo. A aplicao abaixo ilustra isso: import java.util.*; class GarbageExample { private static MeuVetor vetor; public static void main(String args) { vetor = new MeuVetor(); for (int a=0; a <500; a++) vetor.addElement(new StringBuffer("teste")); Runtime rt = Runtime.getRuntime(); System.out.println("Memria Livre: " + rt.freeMemory()); vetor = null; // deixa os 500 StringBuffers sem //referncia System.gc(); System.out.println("Memria Livre: " + rt.freeMemory()); } } class MeuVetor extends Vector { public void finalize() { System.out.println("Vou ser coletado!!"); } }

O mtodo finalize da classe MeuVetor executado antes do objeto ser coletado da memria, a sada deste programa : Memria Livre: 459808 Vou ser coletado!! Memria Livre: 600664

JVM E QUESTO DA SEGURANA


Desde sua criao, sempre considerou com seriedade a questo da segurana. Por isso, praticamente impossvel criar programas em Java para fins maliciosos. Quando um programa em Java executado, seu bytecode precisa passar pelos requisitos de segurana presentes na JVM, que impede a execuo se o cdigo tiver alguma irregularidade. Assim, se no programa houver instrues para acessar reas restritas da memria ou acessar recursos de hardware, a JVM no aprovar o cdigo. Outras linguagens, como C, so executadas diretamente pelo sistema operacional. Com isso, possvel criar programas que acessem recursos crticos do sistema. No caso da linguagem Java, a JVM atua como uma espcie de intermediria entre o programa e o sistema. Sendo assim, at mesmo o acesso a recursos de entrada e sada s feito por meio da JVM.

UM EXEMPLO ATUAL DA UTILIZAO DO JVM


ST lana Mquina Virtual Java para TV Interativa. A STMicroelectronic anunciou a disponibilidade do STJ Engine, uma arquitetura de software projetada para funcionar com a Mquina Virtual Java (JVM). O STJ Engine oferece uma Java Virtual Machine (JVM) otimizada com compilador HotSpot Just-In-Time (JIT) e implementa a interfaces padres como Java debugger (JVMDI) e Java profiling (JVMPI), permitindo debugging e profiling de aplicaes Java. Ao utilizar essas capacidades, os clientes podero aprimorar as capacidades grficas de seus sistemas, permitindo uma interface de usurios muito melhor e recursos interativos como jogos de perguntas e respostas, compra virtual, e outros.

REFERNCIA BIBLIOGRFICA VENNERS, Bill. Inside the Virtual Machine. http://www.mundojava.com.br http://forums.sun.com/index.jspa http://www.ime.usp.br http://www.infowester.com http://www.elektorbrasil.com.br

Você também pode gostar