Mobilidade e Blackboards

Transcrição

1 Uma Máquina Virtual com Suporte à Concorrência, Mobilidade e Blackboards Alex Sandro Garzão, Jorge Luis Victória Barbosa Universidade do Vale do Rio dos Sinos (Unisinos) São Leopoldo, RS, Brasil alexgarzao@bol.com.br, barbosa@exatas.unisinos.br Abstract. This text purposes the HoloVM, a virtual machine with support to concurrency, mobility and blackboards, realizing symbol processing. It was created to supply Hololanguage necessities, but it can be used as execution environment by another languages. After explanations about the Holoparadigm, Hololanguage and HoloJava, will be shown concepts about this virtual machine, the HoloASM (assembler to the machine language of HoloVM) and the HoloC (compiler to the Hololanguage), tools which are being used for help in validation and use of this machine. Keywords: Distributed Systems, Parallel programming, Languages and Programming Techniques Resumo. Este texto propõe a HoloVM, uma máquina virtual com suporte à concorrḙncia, mobilidade e blackboards, realizando processamento simbólico. Foi criada para suprir as necessidades da Hololinguagem, mas pode ser utilizada como ambiente de execução para outras linguagens. Após explicações sobre o Holoparadigma, a Hololinguagem e o HoloJava, serão apresentados conceitos desta máquina virtual, o HoloASM (montador assembly para a linguagem de máquina da HoloVM) e o HoloC (compilador para a Hololinguagem), ferramentas estas que estão sendo utilizados para auxiliar na validação e uso desta máquina. Palavras-chave: programação Sistemas distribuídos, Programação paralela, Linguagens e técnicas de

2 1. Introdução O Holoparadigma[13, 10, 11] é um modelo multiparadigma que integra os conceitos de paradigmas básicos (imperativo, orientado a objetos e lógico) e estimula a exploração automática do paralelismo e distribuição[7, 5]. Para uma melhor exploração deste modelo foram criadas a Hololinguagem[12, 13] (linguagem de programação que implementa os conceitos propostos neste modelo) e o HoloJava[9] (ferramenta que traduz programas Holo para a linguagem Java). O HoloJava, mesmo não suprindo todas as necessidades deste modelo, proporcionou subsídios suficientes para uma rápida prototipação do ambiente de desenvolvimento, bem como a explicitação de vários recursos inerentes deste novo paradigma de software. Mesmo existindo diferentes propostas e implementações de máquinas virtuais (por exemplo, JVM[18], WAM[6] e Mozart[21]), nenhuma conseguiu suprir todas as necessidades propostas pelo Holoparadigma, algumas por não terem recursos essenciais e outras pelo baixo desempenho apresentado[8]. Frente a estas dificuldades surgiu a proposta da HoloVM: uma máquina virtual com suporte nativo à concorrência (entes concorrentes e ações concorrentes), mobilidade e blackboards, realizando processamento simbólico, proporcionando uma melhor utilização destes recursos e tornando a execução dos programas holo mais eficiente. A idéia inicial era adaptar a JVM as necessidades da Hololinguagem; porém, ela não possui instruções nativas para controle da mobilidade e blackboards e o seu conjunto de instruções não pode ser expandido. O texto está organizado em 5 seções. A segunda seção apresenta um estudo sobre o projeto Holo; a terceira seção apresenta uma descrição da HoloVM, abordando aspectos como estruturas internas, exploração da concorrência e formas de sincronia; a quarta seção aborda o protótipo implementado; e a quinta seção contém a conclusão deste artigo. 2. Holoparadigma, Hololinguagem e HoloJava O Holoparadigma é um modelo multiparadigma orientado ao desenvolvimento de software paralelo e distribuído; possui uma semântica simples e distribuída que estimula a exploração automática da distribuição (implícita) e do paralelismo. Esta semântica estabelece a utilização de duas unidades de modelagem: o ente, que é a principal abstração do Holoparadigma, e o símbolo, que é utilizado para descrever os entes e suas relações. Um ente elementar (figura 1a) é organizado em três partes: interface, comportamento e história. Um ente composto (figura 1b) possui a mesma organização de um ente elementar, porém suporta a existência de outros entes na sua composição (entes componentes), assemelhando-se a um grupo. Neste caso, a história atua como um espaço compartilhado vinculado ao grupo. Cada ente possui uma história que fica encapsulada no seu interior e, no caso dos entes compostos, é compartilhada pelos entes componentes. Sendo assim, podem existir vários níveis de encapsulamento da história; porém, os entes acessam somente a história em um nível. A composição varia de acordo com a mobilidade dos entes em tempo de execução. A figura 1c mostra um ente composto de três níveis e exemplifica a história encapsulada. Figura 1: Tipos de entes 2

3 O Holoparadigma propõe a utilização do processamento simbólico como principal instrumento para o tratamento de informações, característica esta herdada do paradigma em lógica. A interface descreve suas possíveis relações com os demais entes; o comportamento contém ações que implementam sua funcionalidade; e a história é um espaço de armazenamento compartilhado no interior de um ente. Essa estrutura assemelha-se a um objeto[22] do paradigma orientado a objetos. Do ponto de vista estrutural, a principal diferença consiste na história, a qual atua como uma forma alternativa de comunicação e sincronização. Além disso, existe maior enfoque na composição e suporte implícito da mobilidade. A mobilidade é a capacidade que permite o deslocamento de um ente. No âmbito do Holoparadigma existem dois tipos: (1) a mobilidade lógica, que relaciona-se com o deslocamento a nível de modelagem, ou seja, sem considerações sobre o ambiente de execução; (2) a mobilidade física, que relaciona-se com o deslocamento entre nodos de uma arquitetura distribuída. Neste contexto, um ente se move quando desloca-se de um nodo para outro. O Holoparadigma propõe dois modos de invocação: (1) a afirmação, que envolve um fluxo de informação unidirecional, não existindo sincronismo. Podem ser utilizadas para comunicação assíncrona e para inserção de informações na interface, no comportamento e na história; (2) a pergunta, que envolve um fluxo de informação bidirecional, estabelecendo sincronismo. As perguntas podem ser utilizadas para comunicação síncrona e para retirada de informações da interface, do comportamento e da história. A Hololinguagem [2, 12, 13] é uma linguagem que implementa os conceitos propostos pelo Holoparadigma; é uma linguagem multiparadigma direcionada para o desenvolvimento de sistemas distribuídos. Neste sentido, destacam-se como suas principais características: (1) sem tipos e orientada ao processamento simbólico; (2) programação de alta ordem, ou seja, símbolos representando entes e suas partes (interface, comportamento e história) podem ser manipulados através de variáveis e operações da linguagem; (3) blackboard hierárquico; (4) mobilidade; (5) suporte a ações concorrentes e entes concorrentes; (6) sintaxe imperativa baseada na linguagem Pascal. Um programa é composto de descrições de entes (estáticos). Visando a realização de testes de Holoprogramas no menor espaço de tempo possível, foi criado uma ferramenta para conversão de programas[20] denominada HoloJava[12, 9]. Esta ferramenta converte programas em Holo (linguagem origem) para programas em Java (linguagem destino); porém não implementa algumas características propostas na Hololinguagem porque Java não possui suporte para estas características. Portanto, a conversão torna-se limitada e o uso de bibliotecas complementares torna-se necessário. Mesmo com limitações, diversos programas em Holo podem ser executados, permitindo assim a obtenção de resultados e a realização de análises. 3. HoloVM A HoloVM cria uma camada de abstração entre os programas e a máquina física em que está sendo executada, possibilitando que um bytecode Holo seja executado em qualquer plataforma onde exista uma implementação desta máquina. Possui um conjunto de instruções e manipula algumas áreas de memória em tempo de execução. A sua criação, como citado em [8], tornará a execução de programas Holo mais eficiente. Como a proposta é criar condições para uma melhor exploração da Hololinguagem, sua especificação está focada nos recursos que não foram possíveis de serem implementados no HoloJava. É utilizado um formato binário predefinido denominado arquivo hvm. Este arquivo contém uma tabela de símbolos e as instruções (bytecodes) à serem executadas. Qualquer compilador pode gerá-lo e usufruir dos recursos presentes nesta nova máquina virtual. Como realiza processamento simbólico, não existe a definição explícita de variáveis e tipos; as variáveis são criadas sob demanda e a verificação de tipos é feita durante a execução do bytecode. Para processamento interno, existem três tipos básicos de dados: símbolos, números e strings. Possui duas pilhas: (1) a pilha de operandos (OperandStack), que é similar as pilhas de linguagens con- 3

4 vencionais como C e Pascal, sendo utilizada para armazenar resultados parciais de cálculos, parâmetros necessários à execução de uma ação ou ente e informações de retorno destas ações. É manipulada explicitamente através de comandos de load e store. Por exemplo, para somar dois números utiliza-se a instrução lsb (load symbol) para carregar o primeiro e o segundo número e, após isso, a instrução add, que irá retirar esses números, somá-los e colocar o resultado nesta mesma pilha; (2) a pilha de controle (ControlStack) que também é similar as pilhas de linguagens convencionais como C e Pascal, sendo utilizada apenas para controle interno de um fluxo de execução, armazenando informações como o endereço de retorno e as variáveis locais de uma ação. Não há instruções específicas para acessar esta pilha, ficando seu uso restrito à máquina virtual. É utilizada implicitamente através de instruções de manipulação de variáveis e de invocação e término de ações. Cada ente possui sua pilha de operandos e pilha de controle, criadas na clonagem deste ente e destruídas no momento de sua extinção. Como a HoloVM é uma máquina de pilha, o conceito de registradores, normalmente utilizados em máquinas reais, somente existem para uso interno. A História, o Comportamento e a Interface são implementados através de blackboards (figura 2). Qualquer invocação feita à eles resume-se a uma invocação implícita para um blackboard[23]. Essa idéia surgiu da similaridade existente entre eles. Com isso, ao fazer uma afirmação para a história está sendo inserido um fato nesta história; ao fazer uma afirmação para o comportamento está sendo inserida uma ação neste comportamento. Da mesma forma é possível retirar uma ação ou aguardar que seja criada. Em suma, características existentes nos blackboards estão implementadas e são utilizadas tanto para a invocação da história, do comportamento e da interface. Figura 2: Invocações implícitas a um blackboard Para a exploração da concorrência está sendo utilizado a multiprogramação leve (multithreading), de forma a obter vários fluxos de execução dentro de um mesmo processo. Estes fluxos de execução, ou threads, são considerados processos leves porque todos os recursos alocados a um processo são compartilhados por todas as suas threads (como a descrição de recursos, por exemplo), tornando-as menos onerosas ao sistema operacional[17]. Além disto, o multithreading permite a exploração imediata do paralelismo real das arquiteturas SMP. A unidade básica de execução (fluxo de execução) denomina-se BCE (ByteCodeExecutor), demonstrado na figura 3. Cada ente possui sua própria Pilha de Operandos, Pilha de Controle e três blackboards: História, Comportamento e Interface. O BCE, por definição, é uma thread de execução, e sempre está associado a um ente, utilizando deste seus blackboards e pilhas durante sua execução. Conforme pode ser visto na figura 4, o BCE auxilia na exploração da concorrência inter-entes (entes concorrentes) e intra-entes (ações concorrentes). Os blackboards foram omitidos para simplificar a figura. Sempre que um ente é criado, um BCE é designado para executá-lo, possibilitando assim a exploração de entes concorrentes. As ações, quando invocadas de forma assíncrona, também são associadas a um BCE, possuindo seu próprio fluxo de execução e possibilitando a exploração de ações concorrentes. A diferença entre entes e ações concorrentes é que as ações não possuem blackboards, mas compartilham os blackboards do ente ao qual pertencem. Cada ente, como citado acima, possui sua própria história, e também compartilha a história do ente que 4

5 Figura 3: Unidade básica de execução (BCE) Figura 4: Exploração da concorrência na HoloVM o criou (ente criador). Cada ente pode realizar invocações implícitas para essa história compartilhada ou explícitas para outros entes. Como é compartilhada por todos os entes que estejam no mesmo nível (figura 1c), torna-se um espaço tanto para troca de informações como forma de sincronia entre vários entes, possibilitando que as ações troquem informações através do seu uso e através de invocações explícitas. A figura 5 tem um exemplo em Hololinguagem que explora a concorrência existente na HoloVM. Neste exemplo, o ente principal holo clona dois entes (ente 1 e ente 2), executa seu processamento e depois aguarda o término destes entes antes de terminar sua execução. A figura 6 demonstra os fluxos de execução (BCEs) gerados por este exemplo. Após a clonagem do ente 1 e ente 2, ambos os entes (holo, ente 1 e ente 2) estão sendo executados concorrentemente. Após o término da sentença for, o ente holo fica aguardando que os entes clonados terminem, utilizando sua história (que é compartilhada por todos os entes que ele clonou) como forma de sincronia, aguardando que seja inserido o símbolo terminei com um argumento indicando qual ente terminou. Os entes clonados, após executarem sua tarefa, inserem na história externa (história do ente que o criou que, neste caso, é o ente holo) o símbolo terminei com um argumento contendo sua identificação. A figura 7 tem um exemplo em Hololinguagem que demonstra como é possível explorar o particionamento dinâmico[19, 24]. Várias unidades de execução compartilham tarefas à serem realizadas. Essas tarefas são os números à serem calculados e as unidades de execução calculam o fatorial destes números. Os BCEs não possuem um conjunto predeterminado de números à serem calculados. Ao invés disso, através de 5

6 holo() { holo() { // definição do ente principal clone(ente_concorrente(1), ente_1), // clonagem de ente_1 clone(ente_concorrente(2), ente_2), // clonagem de ente_2 for X := 1 to 5 do { writeln( Ente d_holo esta na iteracao, X ) history#terminei(#id), writeln( Ente, Id, terminou... ), // perguntas destrutivas history#terminei(#id), writeln( Ente, Id, terminou... ) // para a história ente_concorrente() { ente_concorrente(id) { for X := 1 to 20 do { writeln( Ente, Id, esta na iteracao, X) out(history)!terminei(id) // definição do ente_concorrente // afirmação para a história externa Figura 5: Exploração da concorrência na Hololinguagem Figura 6: BCEs criados pelo programa da figura 5 uma pergunta destrutiva não-bloqueante, tentam retirar um número da história. Se conseguirem (existem números a serem calculados ainda) eles executam o cálculo sobre este número, colocam o resultado na história e tentam retirar outro número. Se não existir mais números para serem calculados, terminam sua execução. A HoloVM utiliza algumas áreas de dados durante a execução do bytecode. Algumas são criadas na sua inicialização e destruídas somente quando termina enquanto que outras estão associadas a um ente, sendo criadas quando este ente é criado e destruídas quando este ente é extinto. Existem três áreas distintas: (1) entes estáticos, que é uma imagem dos entes contidos em um arquivo hvm. É similar a área de armazenamento para código compilado de uma linguagem convencional, ou similar ao segmento texto de um processo UNIX[18]; (2) entes dinâmicos, que é responsável por armazenar a imagem dos entes em execução. Durante a criação de um ente, é criada uma entrada nesta área idêntica a sua imagem estática (armazenada na área de entes estáticos). Durante a execução, esta área pode sofrer mudanças como inserção, remoção ou alteração em suas ações; (3) Constant Pool (tabela de constantes), que é uma imagem estática da constant pool contida no arquivo hvm. Esta área é compartilhada por todos os entes em execução, sendo similar à tabela de símbolos de um compilador tradicional[4, 18]. Nesta área são armazenados constantes necessárias na descrição dos entes e na execução das instruções, contendo o tipo, o tamanho e a informação armazenada. Sempre que uma ação é invocada, é criada na pilha de controle uma entrada (frame) para armazenar suas 6

7 holo() { // definição do ente holo holo() { for X := 1 to 4 do { clone(calc_fat(x), null) // clonagem de entes sem identificá-los for X := 1 to 20 do { history#fat_result(#being,#value,#result), // pergunta destrutiva para a história writeln( Ente, Being, calculou o fatorial de, Value, :, Result) // exibe o resultado history { // fatos históricos fat(10). fat(5). fat(7). fat(2). fat(3). fat(2). fat(1). fat(9). fat(8). fat(5). fat(4). fat(8). fat(1). fat(5). fat(6). fat(10). fat(4). fat(8). fat(4). fat(7). calc_fat() { // definição do ente calc_fat calc_fat(id) { while(out(history)?#fat(#value)) do { // pergunta destrutiva não-bloqueante para a história fat(id, Value) // invoca a ação fat fat(id, Value) { // calcula o fatorial de um número Aux := Value, Result := 1, while(aux > 1) do { Result := Result * Aux, Aux := Aux - 1 out(history)!fat_result(id, Value, Result) // insere na história externa o resultado Figura 7: Cálculo do fatorial de 20 números com entes concorrentes variáveis (escopo local). Este frame é visível apenas para a ação que o criou [22]. No término da execução desta ação, este frame é retirado da pilha de controle e as variáveis destruídas. É possível inserir e remover ações de um ente durante sua execução. A figura 8 demonstra um programa Holo que utiliza este recurso. holo() { // definição do ente holo holo() { clone(ente,null), // clona um ente sem identificação (null) acao(), // invoca a ação acao sem argumentos acao(a), // invoca a ação acao com um argumento acao(a,b) // invoca a ação acao com dois argumentos ente() { // definição do ente ente ente() { out(behavior)!acao/0, // insere a ação acao/0 no comportamento do ente externo out(behavior)!acao/1, // insere a ação acao/1 no comportamento do ente externo out(behavior)!acao/2 // insere a ação acao/2 no comportamento do ente externo acao() { // acao/0 writeln( Em acao/0. Nenhum argumento. ) acao(vlr1) { // acao/1 writeln( Em acao/1. Argumento 1:,Vlr1) acao(vlr1,vlr2) { // acao/2 writeln( Em acao/2. Argumento 1:,Vlr1, Argumento 2:,Vlr2) Figura 8: Insere ações durante a execução A HoloVM possui 54 instruções. Uma instrução consiste em um opcode especificando a operação à ser executada, seguida de zero ou mais operandos, informando argumentos ou dados que serão utilizados na operação. Algumas instruções não possuem operandos e consistem apenas do opcode. O número dos operandos é determinado pelo opcode. Existem dois tipos de operandos: (1) gerados em tempo de compilação, que são embutidos nas instruções; (2) calculados em tempo de execução, que são colocados 7

8 na pilha de operandos. Mesmo tendo duas áreas para serem trabalhadas, estes operandos representam a mesma informação: valores para serem utilizados durante a execução. Essa metodologia gera flexibilidade e garante um código compilado mais compacto[14, 15]. A figura 9a mostra um trecho de código na linguagem Holo. Este código calcula uma expressão matemática, armazena o resultado na variável X, e logo após exibe o conteúdo desta variável. Na figura 9b encontra-se a tradução para bytecode Holo; por sua vez, a figura 9c mostra o estado da pilha de operandos após a execução de cada instrução. Figura 9: Exemplo de tradução de holo para bytecode As instruções estão divididas em 9 categorias: (1) ações específicas da Hololinguagem: são instruções que executam ações predefinidas da linguagem holo; (2) controle da pilha de operandos: são instruções de load e store. Transferem valores entre as variáveis locais, pilha de operandos e ações da Hololinguagem; (3) controle do fluxo de execução: são instruções, condicionais ou incondicionais, que forçam um desvio no fluxo normal de execução; (4) operações aritméticas: são instruções que calculam um resultado que é tipicamente uma função de dois valores na pilha de operandos, colocando o resultado de volta na pilha de operandos; (5) operações lógicas: são instruções que executam operações lógicas sobre informações contidas na pilha de operandos. Após a execução, cada operação armazena o resultado na pilha de operandos; (6) operações booleanas: são instruções que executam operações booleanas sobre informações contidas na pilha de operandos. Após a execução, cada operação armazena o resultado na pilha de operandos; (7) interação com blackboards: são instruções que interagem com os blackboards; (8) mobilidade: nesta categoria existe apenas uma instrução que executa a movimentação de um ente; (9) concorrência: são instruções que implicitamente criam um novo fluxo de execução (BCE) a partir de uma descrição estática. As figuras 10 e 11 demonstram, respectivamente, um exemplo em Hololinguagem e Holoassembly que exibem os números de 1 até 100. holo() { // definição do ente holo holo() { for X := 1 to 100 do { // for variando X de 1 até 100 writeln( X=, X) // exibe o valor de X Figura 10: Programa Holo que exibe os números de 1 até Implementação da HoloVM Foi construído um protótipo da HoloVM para validar esta especificação, desenvolvido na Linguagem C++ e testado no ambiente Linux com o compilador GCC versão As bibliotecas de código necessárias 8

9 holo // definicao do ente holo holo() lsb_1 // carrega o símbolo 1 na pilha sv X // armazena na variável X :for_test lv X // carrega o valor da variável X lsb 100 // carrega o símbolo 100 le // compara os dois símbolos da pilha (less or equal) ifnot for_end // se verdadeiro salta para o label for_end lv X // carrega o valor da variável X wr // exibe o valor wrln // salto de linha (line feed) lv X // carrega o valor da variável X na pilha inc // incrementa sv X // armazena o valor na variável X goto for_test // salta para o label for_test :for_end end end Figura 11: Programa em Holoassembly que exibe os números de 1 até 100 como acesso a blackboards, concorrência e mobilidade foram desenvolvidas. Para auxiliar na validação e testes deste protótipo, houve a necessidade de outras três ferramentas (figura 12): (1) o Holoassembly, a linguagem de máquina da HoloVM; (2) o HoloASM, um montador assembly que traduz programas em Holoassembly para bytecode Holo; (3) o HoloC, um compilador para Hololinguagem que traduz programas Holo para Holoassembly. Figura 12: Ambiente para execução de programas Na figura 13 pode ser vista a execução do programa que calcula o fatorial de 20 números com entes concorrentes (demonstrado na figura 7). Foram realizados testes para medir o desempenho entre a HoloVM e a JVM, verificando pontos positivos e negativos. O ambiente de teste utilizado é demonstrado na Tabela 1. Uma descrição sucinta dos programas escritos em Hololinguagem é apresentada a seguir: hello world: exemplo clássico que exibe a mensagem Hello world!!! e termina sua execução. performance: simula uma mineração usando três minas e um mineiro. O usuário determina quantas operações de mineração serão realizadas em cada mina. travel: simula uma viagem por dois estados brasileiros, visitando cinco municípios. Os estados e municípios são modelados como entes. Exemplifica a composição, mobilidade e o uso de ações predefinidas para obtenção de informações de entes (whereami, whoami e howmany). 9

10 Figura 13: Screenshot da execução do fatorial com entes concorrentes Tabela 1: Ambiente de teste utilizado Sistema operacional Red Hat Linux, vers ão 7.3 Kernel Processador (1) Pentium IV 1.6 Memória RAM 256 MB Compilador C++ GCC 2.96 Compilador Java J2SDK semaphores: suporta o gerenciamento de semáforos. Diversos entes concorrem por um recurso compartilhado usando semáforos para controle da exclusão mútua. O número de entes concorrentes é determinado pelo usuário. philosophers: implementa o clássico programa concorrente Jantar de Filósofos. Os filósofos são implementados como entes. datamining: simula uma mineração usando três minas e um mineiro. buffers: suporta o gerenciamento de buffers. Diversos produtores e consumidores podem acessar de forma concorrente o buffer. Os produtores e consumidores são entes e o sincronismo é realizado pela história que implementa o buffer. O número de produtores e consumidores é determinado pelo usuário. fibo: implementa o cálculo de Fibonacci recursivo. infobeing: demonstra o uso de ações predefinidas da Hololinguagem como howmany, whereami e whoami. interativo: testa o desempenho em um laço for. A quantidade de interações é definida pelo usuário. A cada iteração, o programa exibe uma mensagem avisando a interação atual. calculo intensivo: como o exemplo anterior, também testa o desempenho em um laço for, porém somente exibe uma mensagem no término da execução. O usuário define o número de interações. Para comparar o desempenho entre a HoloVM e a JVM foram realizados testes utilizando-se respectivamente os compiladores HoloC (versão 0.1.0) e HoloJava (versão 1.0). A Tabela 2 apresenta o tempo de execução (em segundos) de cada teste realizado. Analisando-se estas medidas, chegou-se as seguintes conclusões: (1) o desempenho da HoloVM está diretamente relacionado aos recursos que cada exemplo utilizou; (2) o ganho em relação à JVM está relacionado, em alguns casos, ao baixo tempo de inicialização da HoloVM se comparando ao tempo de inicialização da JVM. A JVM realiza verificações no bytecode à ser executado durante a sua inicialização e, quando possível, realiza otimizações neste bytecode. Este protótipo não está realizando verificações ou otimizações na inicialização, o que justificaria o baixo tempo de inicialização; (3) perdas significativas em relação à 10

11 Tabela 2: Tempo de execução dos testes realizados Tempo de Tempo médio 100 execuções de 1 execução Programa Parâmetros HoloVM JVM HoloVM JVM Desempenho hello world performance travel semaphores philosophers dataminig buffers buffers fibo infobeing interativo calculo intensivo JVM estão relacionadas aos programas que fazem uso intensivo de sincronismo ou blackboards. Nestes casos se enquadram os programas que fazem uso intensivo da história para sincronia (como em buffers e semaphores) e os que fazem uso intensivo do comportamento (ações recursivas em fibo, por exemplo); (4) o compilador e o montador holo não estão realizando nenhum tipo de otimização, o que torna este bytecode menos eficiente. Já o compilador Java realiza otimizações durante a geração do bytecode e durante a carga deste arquivo na inicialização da JVM, o que aumenta a eficiência deste bytecode; (5) em programas com baixo grau de paralelismo, a HoloVM mostrou-se menos eficiente. Porém, em programas com alto grau de paralelismo, a HoloVM mostrou-se mais eficiente; (6) a JVM, por não ter a capacidade de inserir e remover ações (métodos) durante sua execução, consegue realizar otimizações que não são possíveis na HoloVM. A JVM verifica a existência de um método apenas uma vez, enquanto que, na HoloVM, as ações são verificadas sempre que são invocadas; (7) a HoloVM realiza verificação dinâmica de tipos durante a execução do bytecode enquanto que, na JVM, essa tarefa é realiza estaticamente pelo compilador. Esta característica torna o bytecode Java mais eficiente. 5. Conclusão Este trabalho propõs a especificação de uma máquina virtual com suporte à concorrência, mobilidade e blackboards, validando esta especificação com a implementação de protótipos para a HoloVM, para o HoloASM e para o HoloC. Destacam-se como principais conclusões deste trabalho: (1) uma máquina de pilha mostrou-se uma forma eficaz de obter-se uma máquina virtual de fácil implementação; (2) comparando com uma máquina com registradores, uma máquina de pilha simplifica a implementação da HoloVM, do HoloC e do HoloASM em alguns aspectos. Isso se deve ao fato de operandos e argumentos serem passados através da pilha de operandos. Porém, otimizações como o uso dos registradores para passagem de argumentos requerem, no caso de uma máquina de pilha, otimizações em tempo de execução[14, 15]; (3) inserção e remoção de ações durante a execução aumenta a flexibilidade da máquina virtual mas diminui o desempenho; (4) uma máquina virtual dinamicamente tipada é mais flexível que uma máquina virtual estaticamente tipada, porém menos eficiente; (5) a HoloVM necessita de modificações para aumentar seu desempenho. Destacam-se os seguintes resultados: (1) núcleo executivo para execução de programas; (2) exploração de conceitos ainda não explorados do Holoparadigma; (3) difundir o uso do gerador de parsers YAPG[16], que foi criado para auxiliar o desenvolvimento do HoloC e do HoloASM; (4) difundir a cultura do software livre, uma vez que todo trabalho aqui realizado é desenvolvido considerando questões ligadas ao desenvolvimento de software livre; Como trabalhos futuros, pode-se citar: (1) especificação e desenvolvimento da DHolo, que proporcionará suporte para a execução de programas em ambiente distribuído; (2) implementação de um simulador para 11

12 a HoloVM; (3) implementação de um debugador para facilitar a busca por erros em programas escritos em Hololinguagem e Holoassembly; (4) suporte ao paradigma lógico e funcional; (5) otimizações no código assembly gerado pelo HoloC; (6) otimizações no protótipo e na especificação da HoloVM. O projeto HoloVM está sendo desenvolvido no contexto criado pelos projetos Opera[3], Appelo[1] e Holoparadigma[2]. Para maiores informações acesse os sites holo e Referências [1] APPELO - Ambiente de Programação Paralela em Lógica [2] Holoparadigma: Software multiparadigma distribuído. holo, [3] OPERA - Prolog Paralelo [4] A. V. Aho, R. Sethi, and J. D. Ullman. Compilers : principles, techniques, and tools. Addison Wesley, [5] G. R. Andrews. Paradigms for process interaction in distributed programs. ACM Computing Surveys, 23(1):49 90, march [6] H. Aït-kaci. Warren s Abstract Machine - A Tutorial Reconstruction. MIT Press, [7] H. E. Bal, G. Jennifer, and A. S. Tanenbaum. Programming languages for distributed computing systems. ACM Computing Surveys, 21(3): , september [8] J. L. V. Barbosa. Holoparadigma: Um Modelo Multiparadigma Orientado ao Desenvolvimento de Software Distribuído. PhD thesis, Universidade Federal do Rio Grande do Sul (UFRGS), Porto Alegre, [9] J. L. V. Barbosa, A. D. Bois, A. Pavan, and C. F. R. Geyer. HoloJava: Translating a distributed multiparadigm language into java. Conferḙncia Latinoamericana de Informática, September [10] J. L. V. Barbosa and C. F. R. Geyer. Princípios do holoparadigma. AST, [11] J. L. V. Barbosa and C. F. R. Geyer. Um modelo multiparadigma para desenvolvimento de software paralelo e distribuído. Workshop Conputação de Alto Desempnho (WSCAD), January [12] J. L. V. Barbosa and C. F. R. Geyer. Uma linguagem multiparadigma orientada ao desenvolvimento de software distribuído. Simpósio Brasileiro de Linguagens de Programação (SBLP 2001), [13] J. L. V. Barbosa, A. C. Yamin, P. K. Vargas, I. Augustin, and C. F. R. Geyer. Holoparadigm: a multiparadigm model oriented to development of distributed systems. International Conference on Parallel and Distributed Systems (ICPADS), [14] M. A. Ertl. Stack caching for interpreters. SIGPLAN 95, [15] M. A. Ertl. Implementation of Stack-Based languagens on Register Machines. PhD thesis, Technische Universitãt Wien, Austria, [16] A. S. Garzão. YAPG: Yet Another Parser Generator [17] A. S. Garzão, L. C. V. Real, and G. G. H. Cavalheiro. Ferramentas para desenvolvimento de um ambiente de programação sobre agregados. Workshop Software Livre (WSL), Maio [18] T. Lindholm and F. Yellin. The Java Virtual Machine specification. Addison Wesley, [19] P. O. A. Navaux, M. E. Barreto, R. B. Ávila, and F. A. D. de Oliveira. Execução de aplicações em ambientes concorrentes. ERAD, pages , [20] A. Pettorossi and M. Proietti. Rules and strategies for transforming functional and logic programs. ACM Computing Surveys, 28(2): , march [21] P. V. Roy. Mobile objects in Distributed Oz. ACM Transactions on Programming Languages and Systems, September [22] R. W. Sebesta. Concepts of Programming Languages. Addison Wesley, [23] S. Vraned and M. Stanojevic. Integrating multiple paradigms within the blackboard framework. IEEE Transactions on Software Engineering, March [24] A. C. Yamin. Escalonamento em sistemas paralelos e distribuídos. ERAD, pages ,