Implementação de uma Heurística de Coleta de Lixo na Máquina Virtual Java

Tamanho: px
Começar a partir da página:

Download "Implementação de uma Heurística de Coleta de Lixo na Máquina Virtual Java"

Transcrição

1 Implementação de uma Heurística de Coleta de Lixo na Máquina Virtual Java Héberte Fernandes de Moraes 1, Luciano J. Chaves 2, Marcelo Lobosco 3 1 Programa de Engenharia de Sistemas e Computação COPPE/UFRJ Caixa Postal Rio de Janeiro RJ Brasil 2 Instituto de Computação Universidade Estadual de Campinas Caixa Postal Campinas SP Brasil 3 Departamento de Ciência da Computação Universidade Federal de Juiz de Fora Campus Universitário Juiz de Fora MG Brasil Abstract. The Garbage Collector mechanism frees the programmer from manually dealing with memory management. This is a standard feature of several programming languages, such as Java, but imposes an additional cost on program execution. An attempt to minimize this cost is to increase the size available for allocations, but memory can be wasted. If too little memory is available for allocation, the number of garbage collections increases, which in turn impacts negatively the computation time. In this work we present, implement and evaluate a new heuristic that aims to adjust automatically the total amount of memory available for allocation. The heuristic was implemented in the Java Virtual Machine. Resumo. O mecanismo de coleta automática de lixo (garbage collection), presente em diversas linguagens de programação, como Java, por um lado libera o programador da tarefa de gerenciar as regiões de memória que sua aplicação não mais utiliza, e por outro adiciona um custo ao tempo total de execução da aplicação. Uma tentativa de minimizar este custo consiste em aumentar o tamanho do espaço disponível para o aplicativo realizar alocações, o que por sua vez pode acarretar em um desperdício de memória. Sob outra perspectiva, a restrição demasiada do espaço disponível para alocação pode causar muitas coletas, conseqüentemente aumentando o tempo total de execução da aplicação. Neste trabalho propomos, implementamos e avaliamos uma nova heurística para adequar automaticamente a quantidade de memória disponível para alocação pelas aplicações que executam na Máquina Virtual Java. 1. Introdução O coletor de lixo (Garbage Collector) foi desenvolvido com o intuito de auxiliar o programador no desenvolvimento de suas aplicações. Em um primeiro momento, cabe ao coletor a tarefa de vasculhar a memória, procurando por regiões alocadas que não podem mais ser acessadas pela aplicação. Estas regiões são denominadas de lixo. Após SBC

2 essa fase inicial, o coletor deve liberar essas regiões de memória, permitindo assim o reuso do espaço para novas alocações. Desta forma, o coletor gerencia automaticamente a utilização da memória por parte do aplicativo. Em linguagens de programação que não contam com este recurso, este papel é desempenhado pelo programador, que é obrigado a especificar explicitamente quais regiões devem ser liberadas. É comum que os programadores incorram em erros durante esse processo, que podem levar a erros fatais na execução dos programas. Com o coletor, o programador fica livre dessa responsabilidade, levando a um gerenciamento mais eficiente dos recursos de memória. O emprego de coletores em linguagens de programação implica em um custo adicional para a aplicação, já que parte do seu tempo de execução é gasto nos processos de identificação e liberação de regiões de memória não mais alcançáveis pela aplicação. Esse custo pode ser muito alto, dependendo das características do aplicativo e do coletor utilizado. Uma forma de minorar ou mesmo eliminar este custo consiste do aumento da quantidade de espaço para o aplicativo realizar alocações: com mais espaço disponível, reduz se a necessidade de liberar memória para o reuso da própria aplicação. Entretanto, disponibilizar muita memória pode constituir se em fonte de desperdício de recursos computacionais. De forma análoga, restringir demais a quantidade de espaço disponível pode levar a ocorrência de muitas coletas de lixo, conseqüentemente aumentando o tempo total de execução da aplicação. Faz se, portanto, necessário atingir um ponto de equilíbrio na quantidade de memória disponibilizada para aplicação. Neste trabalho estudamos esta questão, propondo uma heurística para realizar automaticamente o aumento ou a redução da quantidade de memória disponibilizada para a aplicação. Para avaliar nossa proposta, implementamos a heurística na Máquina Virtual Java (Java Virtual Machine JVM) [Lindholm e Yellin 1999], comparando a com os coletores disponibilizados pela JVM. Os resultados preliminares demonstram que, para algumas aplicações avaliadas, a heurística foi efetiva em seu objetivo de reduzir os custos associados à coleta de lixo. O restante deste trabalho está organizado da seguinte forma: a seção 2 apresenta os mecanismos de coleta de lixo disponibilizados na JVM; a seção 3 apresenta nossa heurística; na seção 4 são apresentados alguns aspectos de sua implementação na JVM; a seção 5 apresenta alguns resultados preliminares da heurística ora proposta; a seção 6 apresenta algumas idéias para trabalhos futuros; enquanto a seção 7 conclui o trabalho. 2. Coleta de Lixo na JVM Existem diversos tipos de algoritmos para coleta de lixo. Segundo Bacon et. al. (2004), os algoritmos existentes podem ser divididos basicamente em dois grandes grupos: a) algoritmos de contagem de referências e b) algoritmos de rastreamento. Os algoritmos de contagem de referências armazenam, para cada objeto, um contador de referência. Esse contador é incrementado sempre que uma nova referência a este objeto é feita. Esse contador é decrementado caso uma dessas referências deixe de existir. Quando o valor do contador chega a zero, o objeto é considerado lixo e é reciclado. Já os algoritmos de rastreamento percorrem todas as referências de memória a partir de um conjunto inicial de referências, denominado conjunto raiz. Todos os objetos direta ou indiretamente alcançáveis a partir do conjunto raiz são mantidos em memória, enquanto os demais são reciclados. SBC

3 Para a gerência de memória a JVM utiliza um mecanismo de rastreamento baseado em gerações. Esse mecanismo consiste do agrupamento dos objetos vivos em três distintas regiões de memória: a) geração jovem, b) geração antiga ou estável e c) a geração permanente. Esta divisão parte do pressuposto de que a maioria dos objetos vive por um período muito curto, enquanto uma pequena porcentagem deles vive por muito tempo [Ungar 1984]. Assim pode se realizar operações de coleta mais constantes apenas na região de memória que abriga os objetos alocados mais recentemente, que ficam localizados na geração jovem. Após um determinado número de coletas, os objetos sobreviventes são promovidos para a geração antiga, conforme ilustrado na Figura 1. Nesta região de memória as coletas não precisam ser tão freqüentes quanto na geração anterior, visto que a chance dos objetos serem referenciados por muito tempo é maior. Na geração permanente são alocados meta dados, como descritores de classes e métodos. As coletas na geração jovem são conhecidas por coletas menores. Quando as gerações antigas e permanente ficam sem espaço, ocorrem as coletas maiores. Uma vantagem deste modelo de coleta baseado em gerações é a possibilidade de utilizar técnicas de coleta de lixo distintas para cada uma das gerações, de acordo com as suas particularidades. Figura 1. Fluxo de movimentação dos objetos A geração jovem na JVM é ainda dividida em três sub regiões: Éden, espaço de sobreviventes de origem e espaço de sobreviventes de destino, conforme ilustra a figura 2. Todas as novas alocações são feitas no Éden. Objetos que sobrevivem a primeira coleta no Éden são copiados para o espaço de sobreviventes de origem. Quando coletas precisam ser realizadas neste espaço, os objetos ainda vivos são copiados para o espaço de sobreviventes de destino. No final da cópia, os espaços de sobreviventes trocam de nomes. Figura 2. Modelo da geração jovem da JVM SBC

4 3. Heurística Proposta O coletor de lixo é considerado um custo adicional na execução dos aplicativos. Para reduzir este custo deve se reduzir o tempo e / ou o número de execuções do coletor, já que quanto menor for o tempo gasto com coletas, menor será o tempo total de execução do aplicativo. Para reduzir o tempo de execução de um coletor devemos levantar seus custos de execução. Baseados nessa informação, procuram se alternativas de implementação para reduzir os custos das funções que demandam maiores tempos de execução. Por exemplo, no caso do coletor da geração jovem, o maior custo está relacionado às operações de cópia dos objetos vivos. Outra forma de reduzir o tempo total de execução do aplicativo é diminuir a quantidade de coletas. Uma das formas de se fazer isto é aumentando a memória disponível para alocação. Entretanto, estaremos desperdiçando memória caso uma quantidade excessiva desta seja disponibilizada para a aplicação. Ficamos, assim, com um dilema: caso uma quantidade insuficiente de memória seja disponibilizada, teremos uma grande quantidade de coletas, aumentando o tempo total de execução dos aplicativos. Disponibilizar muita memória, por outro lado, pode constituir se em desperdício de recursos computacionais. Neste trabalho propomos uma heurística com o intuito de ajustar automaticamente o tamanho do Éden de acordo com as características de consumo de memória do aplicativo em execução. A heurística consiste em verificar o tempo entre certa quantidade de coletas. Se este tempo for relativamente pequeno, o tamanho do Éden é aumentado; se o tempo for relativamente grande, o tamanho do Éden é reduzido; caso contrário mantém se o tamanho atual. A heurística se baseia no pressuposto de que se o tempo entre as coletas for relativamente pequeno, então muitas alocações estão ocorrendo na aplicação. O aumento do Éden é então realizado na tentativa de suprir essas alocações com mais memória, sem que sejam necessárias operações de coleta para disponibilizá la. Por outro lado, se o tempo entre as coletas for relativamente grande, então poucas alocações estão ocorrendo, ou seja, não há a necessidade de haver tanta memória disponível para alocações. Neste caso reduzimos o tamanho do Éden com o intuito de economizar memória. Nossa heurística inspeciona particularmente o Éden por esta ser a região onde a maior parte das coletas ocorre, as coletas menores, mas nada impede que a técnica seja empregada nas demais regiões de memória para diminuir o número de coletas maiores. 4. Aspectos de Implementação da Heurística na JVM A implementação da heurística proposta foi realizada no Hotspot JVM, uma implementação da especificação da máquina virtual Java desenvolvida pela Sun Microsystem. Uma das dificuldades que encontramos para implementar nossa heurística na Hotspot JVM foi o fato desta não permitir a alteração, em tempo de execução, do tamanho da heap. Como nossa heurística exige a alteração do tamanho do Éden durante a execução da aplicação, procuramos alternativas para sua implementação na Hotspot SBC

5 JVM. Nossa solução foi definir, no início da execução da HotSpot JVM, o tamanho máximo do Éden. A partir daí, o tamanho inicialmente disponibilizado para a aplicação foi definido como metade deste tamanho máximo. O Éden, neste caso, pode expandir se até este tamanho máximo previamente definido. O processo de aumento e redução do Éden é feito na classe EdenSpace do DefNewGeneration. Em sua implementação original, esta classe contém o limite inferior e o superior do espaço delimitado para o Éden. Os campos bottom, top e end (figura 3) são usados para delimitar o Éden, sendo bottom e end fixos durante toda a execução da máquina virtual. O campo top indica o ponto no qual um novo objeto pode ser alocado; todo o espaço à esquerda deste ponto contém objetos recém alocados. Quando valor do campo top alcança o valor do end, uma coleta é executada e todos os objetos vivos são retirados deste espaço, e valor do top é substituído pelo valor do bottom. Figura 3. Limites do Éden Para que o ajuste de tamanho do Éden funcionasse, modificamos a classe EdenSpace para criar um novo campo chamado hardend (figura 4). Esse campo tem por finalidade armazenar o limite superior do Éden. Com isso, o valor do campo end pode variar entre o hardend (seu valor máximo), e a metade do espaço delimitado por bottom e hardend (seu valor mínimo). Na inicialização do EdenSpace, os valores dos campos end e hardend são definidos como a figura 4 ilustra, sendo o valor do hardend igual ao final do espaço e o valor do end, o meio do espaço. Figura 4. Novo Limite para o Éden A alteração do tamanho do Éden só é feita após a execução de uma coleta de lixo, já que neste ponto o coletor já moveu todos os objetos vivos para outro espaço. Sendo assim, pode se alterar o campo end para qualquer posição no intervalo definido. Em nossa primeira tentativa de implementação, definimos que o Éden se expande a uma taxa igual à metade do espaço total ainda disponível, ou seja: end=end+ hardend end = hardend+end 2 2 SBC

6 Enquanto houver espaço disponível para realizar o aumento do Éden, o campo é alterado. Deve se salientar que essa alteração só ocorre caso muitas coletas sejam executadas em um intervalo de tempo relativamente curto. Definimos também que a taxa de redução do Éden é igual ao espaço ainda disponível para expansão, ou seja: end=end hardend end =2end hardend A fórmula acima é válida caso o espaço ainda disponível para alocação seja menor que a metade do espaço total do Éden. Caso contrário, a operação de redução tornaria o espaço para alocação igual à zero, o que causaria uma falha na próxima tentativa de alocação de memória na JVM. Devemos também chamar a atenção para outro ponto ligado à redução do Éden: como definimos que a sua taxa de redução é igual ao espaço ainda disponível para expansão, não teríamos qualquer redução caso não existisse mais espaço disponível para o aumento do Éden. Neste caso, definimos que a redução será igual à 1/4 de seu tamanho total, ou seja, 25% de (hardend bottom). O pseudo código abaixo ilustra a implementação de nossa heurística na JVM. Ele é sempre chamado após as operações de coleta de lixo, já que nesse ponto da execução o Éden não contém qualquer objeto, assim não há problemas na alteração de seu tamanho. ColetaDados(); SE (NumeroColetas >= 30) E (TempoEntreColetas <= 300) ENTÃO End := ARREDONDA((HardEnd + End)/2); SENÃO SE (NumeroColetas < 30) E (TempoEntreColetas > 300) ENTÃO SE End = HardEnd ENTÃO End := End - ARREDONDA((HardEnd Bottom)/4); SENÃO End := 2*End HardEnd; Devemos salientar que o método ColetaDados(), como o próprio nome indica, coleta os dados necessário para a realização dos testes da heurística, como a quantidade de coletas realizadas e o tempo decorrido entre elas. 5. Resultados Preliminares Utilizamos um conjunto de aplicativos com o propósito de avaliar o desempenho da heurística implementada no coletor serial da geração jovem. Os aplicativos são: GCOld [Detlefs 2005], GCBench [Boehm], JGFCreateBench, JGFSerialBench, e JGFSORBench, estes últimos parte do suite de aplicativos do Java Grande Fórum [Bull et alli 2000]. GCOld é um benchmark sintético que modela aplicações onde os dados mais antigos são mais propensos a se tornarem lixo. GCBench também é um benchmark sintético que divide a sua execução em duas fases distintas: a) a expansão da heap e b) a alocação e liberação de grandes porções de memória. JGFCreateBench aloca, durante a sua execução, inúmeros tipos de objetos, sem utilizá-los em processamentos posteriores. Como resultado, os objetos alocados têm uma vida extremamente curta, não

7 sobrevivendo a uma primeira limpeza da memória. JGFSerialBench realiza operações de serialização em diversos objetos, ou seja, armazena em disco o estado dos objetos, recuperando-os posteriormente. São construídas durante a sua execução estruturas como árvores, LinkedLists, Arrays e Vectors que são gravados em arquivos e depois carregados novamente em memória. Para cada estrutura são realizadas 4000 iterações de gravação e leitura de arquivos. O consumo de memória nesta aplicação é aproximadamente constante para cada tipo de estrutura de dados. JGFSORBench realiza centenas de iterações do algoritmo Successive Over Relaxation em uma matriz de tamanho NxN. A característica básica deste algoritmo, em termos de uso de memória, é realizar toda a alocação de objetos no início do processamento. Os testes foram realizados em uma máquina com processador AMD Sempron 2800+, 32 bits, com clock de 1.6 Ghz, 128KB de cache L1 e 256KB de cache L2. A máquina em questão tem 1 GB de memória principal e executa Linux Kubuntu 7.10 com kernel Testamos duas versões do jre1.6.0 (Java Runtime Machine) compiladas na própria máquina, senda uma das versões sem alteração de seu código fonte e a outra com a implementação da heurística. Os principais fatores avaliados em nossos testes foram o tempo de execução do aplicativo, o tempo total de pausa, o tempo médio de execução das coletas, a taxa de throughput e o footprint. O throughput representa nesse contexto o percentual de tempo que a JVM não executa coleta de lixo, tendo como referência o tempo total de execução do aplicativo. O footprint é o uso máximo de memória do aplicativo. Para avaliar os resultados obtidos, geramos o log da coleta de lixo para cada uma das aplicações. O aplicativo GCViewer [Tagtraum industries 2005] foi utilizado para visualizar estes arquivos. Cada aplicativo foi executado no mínimo três vezes de forma exclusiva, e a partir dos resultados foi computada uma média dos valores obtidos. O desvio padrão dos tempos de execução foi desprezível. A JVM tem duas versões distintas: cliente e servidor. Essencialmente tratam se de dois compiladores distintos que possuem uma interface comum com o sistema de execução da JVM. A versão cliente tem seu compilador ajustado para executar aplicações que necessitam de a) um tempo de iniciação rápido ou b) pequenos footprints. Já a versão servidor tem o compilador ajustado para aplicações onde o desempenho global é o ponto mais importante. Nosso trabalho avaliou o impacto de nossa heurística nas duas versões, mas, por falta de espaço, neste trabalho reportamos apenas os resultados com a versão cliente. Os testes foram realizados usando duas máquinas Java distintas. A primeira máquina é a HotSpot JVM padrão, executando em sua versão cliente, com tamanho total da heap igual à 256 MB. Para esta máquina padrão variamos o tamanho da geração jovem de três formas distintas: 1) nesta configuração a geração jovem tem um tamanho fixo igual à 32 MB, 2) nesta configuração seu tamanho varia entre 32 MB e 64 MB, e 3) nesta configuração seu tamanho é fixo em 64 MB. Por fim, a segunda máquina Java consiste da HotSpot JVM modificada pela implementação de nossa heurística (4), com heap de 256 MB e a geração jovem variando entre 32 MB e 64 MB. SBC

8 A diferença entre nossa heurística e a implementação da JVM que expande a geração jovem (versão 2) é a forma como as expansões se dão. Na implementação nativa da JVM, quando não há mais espaço disponível na geração jovem, a JVM tenta primeiro expandir o seu tamanho até que o limite especificado seja atingido. Caso seja possível realizar a expansão, a alocação é feita sem que sejam necessárias coletas de lixo. Caso não seja possível, ou seja, caso o limite superior já tenha sido atingido em operações de expansão anteriores, realiza se a coleta de lixo para liberar espaço nesta geração. Logo, na versão 2 avaliada, a expansão da memória é realizada antes que ocorra uma coleta. No caso da nossa heurística, várias coletas ocorrem antes que o tamanho da geração seja modificado. Nossa heurística utiliza justamente as informações das coletas para saber se estão ocorrendo muitas alocações, optando pelo aumento da geração jovem apenas quando este quadro se confirma, enquanto que na implementação nativa da JVM o objetivo é evitar que ocorra uma coleta. Além do mais, podemos reduzir, em tempo de execução, o tamanho da geração quando o espaço adicional de memória não mais se faz necessário. Para a JVM alterada com a heurística proposta neste trabalho, utilizamos a política de aumentar o tamanho do Éden após 30 coletas menores seguidas executadas em intervalo de tempo de 100 milissegundos. A redução do tamanho do Éden se dá sempre que o tempo entre duas coletas consecutivas torna se relativamente grande; no caso deste trabalho isto ocorre quando o intervalo entre duas coletas torna se superior à 3 segundos. Os resultados obtidos são apresentados em tabelas, onde as linhas representam as quatro configurações testadas e as colunas apresentam os resultados das métricas avaliadas. As configurações 1 a 3 foram executadas na máquina HotSpot JVM padrão, sem qualquer modificação, enquanto na versão 4 a máquina HotSpot JVM foi modificada pela implementação de nossa heurística GCOld Este aplicativo cria muitos objetos grandes que são mantidos alocados na memória durante muito tempo. Assim a geração antiga é muito utilizada, o que faz com que coletas maiores sejam realizadas com mais freqüência. Como nossa heurística tenta reduzir a quantidade de coletas menores, esperávamos não ter qualquer ganho neste benchmark. Neste caso, nosso objetivo primário foi verificar se algum overhead seria adicionado para aplicativos com esta característica de uso de memória. Coletor e opções Tabela 1 Resultados do aplicativo GCOld Execução realizada com heap total de 256 mb Tempos (seg) Throughput (%) Footprint (MB) Acumulado Média pausa Execução 1 Client - 32 mb 29,35 103,12 11,450 0, ,00 2 Client >64 mb 28,77 102,88 11,440 0, ,00 3 Client - 64 mb 31,85 141,5 10,420 0, ,00 4 Client - Com heuristica 26,82 119,781 11,920 0, ,00 Observando os resultados da tabela 1 percebemos que a heurística obteve uma taxa de throughput um pouco menor do que as obtidas por outras configurações. SBC

9 Comparado com a configuração 3, a heurística conseguiu reduzir significantemente o desperdício de memória. Apesar da heurística ter obtido o pior tempo acumulado de coletas, o tempo médio de cada uma das pausas foi bem inferior ao da pior configuração e o tempo total da execução da aplicação ficou dentro da média das demais configurações GCBench Essa aplicação tem como característica principal criar uma grande quantidade de objetos com tempo de vida curto, fazendo uma grande quantidade de alocações em toda a sua execução, o que provoca várias coletas menores. Observando os dados coletados da execução do aplicativo (tabela 2), pode se perceber que quanto maior a quantidade de memória disponibilizada para o aplicativo, menor é o tempo acumulado de coletas, resultando em uma redução no tempo total de execução do aplicativo. Tabela 2 Resultados do aplicativo GCBench Execução realizada com heap total de 256 mb Tempos (seg) Compilador - tamanho Throughput (%) Footprint (MB) Acumulado Média pausa Execução 1 Client - 32 mb 36,19 145,55 3,687 0, ,00 2 Client >64 mb 36,17 145,55 3,690 0, ,00 3 Client - 64 mb 73,94 130,78 0,750 0, ,00 4 Client - Com heuristica 43,31 163,344 2,570 0, ,00 A configuração 1 representa a pior execução, considerando o tempo como variável de comparação; do tempo total da execução do aplicativo aproximadamente 36% foram gastos com a execução do aplicativo, ou seja, o custo da execução dos coletores foi muito maior do que o da execução do aplicativo. A configuração 3, que executa o aplicativo com 64 MB para a geração jovem, obteve o melhor tempo de execução. Isso ocorreu devido a quantidade de coletas realizadas ser bem menor, o que tomou cerca de 26% do tempo total de execução. Com relação à heurística, observamos uma redução no tempo total de execução do aplicativo em comparação às configurações 1 e 2, mas não tão bom quanto a obtida pela configuração 3. O aumento do tamanho do Éden, neste caso, foi responsável pela redução no número de coletas, o que em última instância reduz o tempo de execução do aplicativo. A versão da JVM com a heurística reduziu o tempo de execução do aplicativo em 20%, mas com um custo na utilização de memória: na tentativa de adaptar o tamanho do Éden foi necessário utilizar 12% a mais de memória do que as configurações 1 e JGFCreateBench Esse aplicativo tem a mesma característica do GCBench, com a diferença de que a quantidade de objetos que se tornam lixo mais cedo é maior. Nesse aplicativo espera se que uma grande quantidade de coletas menores seja feita. Assim, a expectativa é que os resultados sejam semelhantes aos do GCBench. SBC

10 Os resultados obtidos são apresentados na tabela 3. Pode se perceber que, de forma geral, os resultados para execuções com o tamanho da geração jovem fixo foram piores do que com o tamanho variável. Neste caso, o uso da heurística reduziu o tempo total de execução em 7%, mas o tempo acumulado gasto com coletas foi ligeiramente maior do que o das demais configurações. A média de pausa foi também ligeiramente pior. Esses dois resultados nos levam a concluir que a heurística conseguiu reduzir a quantidade total de coletas na geração jovem, o que levou a redução no tempo total de execução da aplicação, mesmo tendo uma taxa de throughput um pouco mais baixa. Isso pode ter ocorrido pelo fato da heurística disponibilizar ao aplicativo espaço em momentos críticos de alocação, o que não ocorre nas execuções com o tamanho fixo. Tabela 3 Resultados do aplicativo JGFCreateBench Execução realizada com heap total de 256 mb Tempos (seg) Coletor e opções Throughput (%) Footprint (MB) Acumulado Média pausa Execução 1 Client - 32 mb 98,26 32,812 0,9600 0, ,00 2 Client >64 mb 98,12 32,812 0,9600 0, ,00 3 Client - 64 mb 98,27 61,625 0,9600 0, ,00 4 Client - Com heuristica 97,9 61,6 1,0700 0, ,00 Outro ponto que pode ser observado nestes resultados é que, apesar das configurações 4 (heurística) e 2 (heap variando de 32 a 64 MB) terem obtido os mesmos tempos de execução, a configuração 2 consumiu menos memória que a configuração 4. Isso ocorreu porque o objetivo primário da heurística era reduzir a quantidade de coletas; o que acaba fazendo com que uma quantidade maior de lixo seja mantida na memória por mais tempo, o que não ocorre com a configuração JGFSerialBench A heurística proposta obteve, para este aplicativo, ótimos resultados. A redução do tempo total de execução ficou cerca de 11% abaixo da média dos tempos das demais configurações. Isso aconteceu pelo fato deste aplicativo apresentar justamente as características que desejávamos atender com nossa heurística: alocações de grandes quantidades de memória de maneira relativamente constante ao longo de toda a execução. Tabela 4 Resultados do aplicativo JGFSerialBench Execução realizada com heap total de 256 mb Tempos (seg) Coletor e opções Throughput (%) Footprint (MB) Acumulado Média pausa Execução 1 Client - 32 mb 95,92 108,084 3,1200 0, ,00 2 Client >64 mb 96,05 108,086 3,1000 0, ,00 3 Client - 64 mb 97,15 130,055 2,1700 0, ,00 4 Client - Com heuristica 96,09 94,969 2,7200 0, ,00 Deve se chamar a atenção para outro aspecto interessante: o uso total de memória (footprint) foi menor na heurística do que nas outras configurações. Isso ocorreu basicamente porque os objetos alocados tornaram se lixo ainda na geração jovem, quando a heurística já havia disponibilizado todo o espaço possível para SBC

11 alocação. Acreditamos que isso evitou operações de cópia destes objetos para outros espaços de memória, o que por fim reduziu o tempo médio de cada operação de coleta e o tempo total de execução do programa JGFSORBench Esse aplicativo realiza muito processamento, alocando os dados necessários no início da execução. Espera se que poucas coletas sejam realizadas e, assim como GCOld, nossa heurística não traga grandes ganhos para a sua execução. Esperamos então repetir os resultados de GCOld, não adicionando grandes overheads para a execução da aplicação. A configuração 3 obteve os melhores resultados, mas a diferença em comparação as demais configurações é mínima. Como era desejável, em aplicativos que realizam poucas operações de coleta de lixo na geração jovem, o uso da heurística não adicionou overheads, o que demonstra que a heurística não possui grandes custos adicionais de implementação. De fato, podemos até observar pequenas vantagens em sua utilização, já que o footprint foi menor com a nossa heurística do que as configurações que utilizam a mesma quantidade de memória (32 MB). Tabela 5 Resultados do aplicativo JGFSORBench Execução realizada com heap total de 256 mb Tempos (seg) Coletor e opções Throughput (%) Footprint (MB) Acumulado Média pausa Execução 1 Client - 32 mb 98,97 65,684 0,0800 0, ,00 2 Client >64 mb 98,97 65,684 0,0800 0, ,00 3 Client - 64 mb 99,86 61,625 0,0100 0, ,00 4 Client - Com heuristica 98,93 63,656 0,0800 0, ,00 6. Trabalhos Futuros Nosso trabalho encontra se em fase inicial de desenvolvimento, de forma que temos várias propostas de trabalhos futuros. A primeira proposta consiste da avaliação dos parâmetros que utilizamos para expandir e reduzir o tamanho do Éden. Acreditamos que um ajuste nas taxas de expansão e de redução do tamanho da heap, bem como nos parâmetros que disparam estas ações, podem melhorar o desempenho da heurística. Uma outra proposta consiste de ajustar dinamicamente estes parâmetros conforme o comportamento da aplicação. Outra proposta consiste da aplicação de nossa heurística nas demais gerações do coletor, ou mesmo da criação de uma heurística específica para estas. Acreditamos que o emprego de uma heurística para a geração antiga, por exemplo, poderia impactar positivamente os resultados dos aplicativos que mantém dados alocados por um período longo de tempo, como é o caso do GCOld. Gostaríamos também de avaliar o uso de nossa heurística em outras aplicações, de forma a avaliar melhor o impacto de nossa heurística em suas execuções. Pretendemos também instrumentar a JVM para colher mais informações a respeito das coletas, de forma a termos mais informações para fazermos nossas avaliações de desempenho. Por fim, nossa última proposta consiste de um melhoramento nos algoritmos de coleta por cópia hoje implementados na HotSpot JVM. Gostaríamos de avaliar o impacto do algoritmo Mark Lazy Sweep [Jones e Lins 1996] na geração jovem. Esse algoritmo consiste da SBC

12 marcação dos objetos vivos, assim como ocorre no algoritmo de cópia. Entretanto, a cada alocação de novos objetos, esse algoritmo procura na heap por espaços não marcados que sejam suficientemente grandes para comportar os novos objetos. Assim, esse algoritmo reduz o tempo de pausa do coletor, transferindo seu custo para a fase de alocação. 7. Conclusão Neste trabalho, propomos, implementamos e avaliamos na HotSpot JVM uma nova heurística para realizar automaticamente o ajuste do tamanho da memória de acordo com as características de consumo de memória do aplicativo em execução. A heurística proposta verifica o tempo decorrido dentre certas quantidades de coletas de lixo. Dependendo do tempo decorrido, aumenta se ou reduz se a memória disponibilizada para armazenar os objetos recém alocados. A heurística baseia se no fato de que tempos curtos entre coletas apontam muitas alocações ocorrendo na aplicação. Aumentamos então a região de memória destinada a armazenar objetos recém alocados na tentativa de suprir essas alocações com mais memória, sem que sejam necessárias operações de coleta para disponibilizá la. Analogamente, se o tempo entre as coletas for relativamente grande, concluímos que poucas alocações estão ocorrendo. Neste caso reduzimos o tamanho da memória com o intuito de economizá la. A heurística mostrou se uma boa alternativa para aplicativos que, ao longo de sua execução, alocam grandes quantidades de objetos e os utilizam por pouco tempo, sem acarretar em aumento de custos para aplicativos com características distintas. Referências Lindholm, T.; Yellin, F. (1999) The Java Virtual Machine Specification, 2nd Edition, Prentice Hall PTR. Bacon, D.; Cheng, P.; Rajan, V. T. (2004) A Unified Theory of Garbage Collection. In: ACM SIGPLAN Notices, Vol. 39, Issue 10, pp Nova Iorque: ACM Press. Ungar, D. M. (1984) Generation scavenging: A non-disruptive high-performance storage reclamation algorithm. In: ACM SIGPLAN Notices, vol. 19, issue 5, pp , ACM, Boehm, H. An Artificial Garbage Collection Benchmark Detlefs, D. (2005) GCOld: a benchmark to stress old-generation collection, s132dpihr2?template.filename=admin/printing.template Bull, J. M.; Smith, L. A.; Westhead, M. D.; Henty, D. S.; Davey, R. A.. (2000) A Benchmark Suite for High Performance Java, In: Concurrency: Practice and Experience, vol. 12, pp , Tagtraum industries, inc (2005) Jones, Richard e Lins, Rafael. (1996). Garbage Collection: Algorithms for automatic dynamic memory management. Publicado por John Wiley & Sons. 329p. SBC

Garbage Collection. Automatic Garbage Collection. Introdução. Fontes

Garbage Collection. Automatic Garbage Collection. Introdução. Fontes Fontes Garbage Collection Compiladores II 1 Modern Compiler Implementation in java: capítulo 13 Artigos : Garbage Collection in an Uncooperative Environment de Boehm e Weiser (Software Practice and Experience

Leia mais

Coleta de Lixo na JVM

Coleta de Lixo na JVM Coleta de Lixo na JVM Adriano da Silva Castro Universidade Federal de Juiz de Fora Instituto de Ciências Exatas Departamento de Ciência da Computação Bacharelado em Ciência da Computação Orientador: Prof.

Leia mais

2.1. Princípios de garbage collection Garbage Collector

2.1. Princípios de garbage collection Garbage Collector Capítulo 2 Java Virtual Machine Com a JVM no centro da Plataforma Java, conhecer seu funcionamento interno é essencial para qualquer aplicação Java. Muitas vezes, deixamos de lado ajustes importantes de

Leia mais

Tutorial Gerência de memória em Java

Tutorial Gerência de memória em Java Tutorial Gerência de memória em Java Edição 1.0 (outubro 2005) Helder da Rocha (helder.darocha@gmail.com) 1 Arquitetura da JVM, memória e algoritmos de coleta de lixo 2 Arquitetura da HotSpot JVM e otimização

Leia mais

Análises Geração RI (representação intermediária) Código Intermediário

Análises Geração RI (representação intermediária) Código Intermediário Front-end Análises Geração RI (representação intermediária) Código Intermediário Back-End Geração de código de máquina Sistema Operacional? Conjunto de Instruções do processador? Ambiente de Execução O

Leia mais

PROGRAMAÇÃO ORIENTADA A OBJETOS EM JAVA*

PROGRAMAÇÃO ORIENTADA A OBJETOS EM JAVA* PROGRAMAÇÃO ORIENTADA A OBJETOS EM JAVA* Adair Santa Catarina Curso de Ciência da Computação Unioeste Campus de Cascavel PR Fev/2014 *Adaptado de PACHECO, R C S & RIEKE, R N INE UFSC Disponível em: http://wwwstelaufscbr/~pacheco/dsoo/htm/downloadshtm

Leia mais

Memory Leak em Java?

Memory Leak em Java? 1 Memory Leak em Java? Saiba como memory leaks se manifestam em Java e como evitá-los Sobre o Autor Carlos Eduardo G. Tosin (carlos@tosin.com.br) é formado em Ciência da Computação pela PUC-PR, pós-graduado

Leia mais

AULA 13 - Gerência de Memória

AULA 13 - Gerência de Memória AULA 13 - Gerência de Memória omo sabemos, os computadores utilizam uma hierarquia de memória em sua organização, combinando memórias voláteis e não-voláteis, tais como: memória cache, memória principal

Leia mais

Java de missão crítica. Um artigo técnico da Oracle

Java de missão crítica. Um artigo técnico da Oracle Java de missão crítica Um artigo técnico da Oracle Java de missão crítica A família de produtos Oracle JRockit é um portfólio abrangente de soluções de tempo de execução de Java que aproveita a JVM básica

Leia mais

A Linguagem Algorítmica Estrutura de Repetição. Ex. 2

A Linguagem Algorítmica Estrutura de Repetição. Ex. 2 Estrutura de Repetição. Ex. 2 A ESTRUTURA Enquanto faça{} É MELHOR UTILIZADA PARA SITUAÇÕES ONDE O TESTE DE CONDIÇÃO (V OU F) PRECISA SER VERIFICADO NO INÍCIO DA ESTRUTURA DE REPETIÇÃO.

Leia mais

Qual é o melhor? Há um ano, todas as principais

Qual é o melhor? Há um ano, todas as principais Comparativo dos sistemas de arquivos para Linux CAPA Qual é o melhor? Será que os novatos Btrfs e Ext4 superam os sistemas de arquivo tradicionais do Linux? por Marcel Hilzinger Há um ano, todas as principais

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Aula 6 Estrutura de Sistemas Operacionais Prof.: Edilberto M. Silva http://www.edilms.eti.br Baseado no material disponibilizado por: SO - Prof. Edilberto Silva Prof. José Juan Espantoso

Leia mais

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de:

Capítulo 1. Introdução. 1.1 Linguagens. OBJETIVOS DO CAPÍTULO Ao final deste capítulo você deverá ser capaz de: i Sumário 1 Introdução 1 1.1 Linguagens....................................... 1 1.2 O que é um Compilador?................................ 2 1.3 Processadores de Programas: Compiladores, Interpretadores

Leia mais

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com

Sistemas Operacionais 2014 Introdução. Alexandre Augusto Giron alexandre.a.giron@gmail.com Sistemas Operacionais 2014 Introdução Alexandre Augusto Giron alexandre.a.giron@gmail.com Roteiro Sistemas Operacionais Histórico Estrutura de SO Principais Funções do SO Interrupções Chamadas de Sistema

Leia mais

CA Nimsoft Monitor Snap

CA Nimsoft Monitor Snap CA Nimsoft Monitor Snap Guia de Configuração do Monitoramento do Jboss do Nimsoft jboss série 1.3 Aviso de copyright do CA Nimsoft Monitor Snap Este sistema de ajuda online (o Sistema ) destina-se somente

Leia mais

Programação de Computadores II: Java. / NT Editora. -- Brasília: 2014. 82p. : il. ; 21,0 X 29,7 cm.

Programação de Computadores II: Java. / NT Editora. -- Brasília: 2014. 82p. : il. ; 21,0 X 29,7 cm. Autor José Jesse Gonçalves Graduado em Licenciatura em Matemática pela Universidade Estadual de São Paulo - UNESP, de Presidente Prudente (1995), com especialização em Análise de Sistemas (1999) e mestrado

Leia mais

LABORATÓRIO DE SISTEMAS OPERACIONAIS. PROFª. M.Sc. JULIANA HOFFMANN QUINONEZ BENACCHIO

LABORATÓRIO DE SISTEMAS OPERACIONAIS. PROFª. M.Sc. JULIANA HOFFMANN QUINONEZ BENACCHIO LABORATÓRIO DE SISTEMAS OPERACIONAIS PROFª. M.Sc. JULIANA HOFFMANN QUINONEZ BENACCHIO Gerenciamento de Memória no Linux O Linux é um sistema operacional com memória virtual paginada, isto quer dizer que

Leia mais

Capacidade = 512 x 300 x 20000 x 2 x 5 = 30.720.000.000 30,72 GB

Capacidade = 512 x 300 x 20000 x 2 x 5 = 30.720.000.000 30,72 GB Calculando a capacidade de disco: Capacidade = (# bytes/setor) x (méd. # setores/trilha) x (# trilhas/superfície) x (# superfícies/prato) x (# pratos/disco) Exemplo 01: 512 bytes/setor 300 setores/trilha

Leia mais

Sistemas de Informação. Sistemas Operacionais 4º Período

Sistemas de Informação. Sistemas Operacionais 4º Período Sistemas de Informação Sistemas Operacionais 4º Período SISTEMA DE ARQUIVOS SUMÁRIO 7. SISTEMA DE ARQUIVOS: 7.1 Introdução; 7.2 s; 7.3 Diretórios; 7.4 Gerência de Espaço Livre em Disco; 7.5 Gerência de

Leia mais

BC1518-Sistemas Operacionais Memória Virtual (aula 9)

BC1518-Sistemas Operacionais Memória Virtual (aula 9) BC1518-Sistemas Operacionais Memória Virtual (aula 9) Prof. Marcelo Z. do Nascimento marcelo.nascimento@ufabc.edu.br Roteiro Memória Virtual Paginação sob demanda Cópia na escrita Algoritmos de Substituição

Leia mais

JAVA VIRTUAL MACHINE (JVM)

JAVA VIRTUAL MACHINE (JVM) JAVA VIRTUAL MACHINE (JVM) Por Leandro Baptista, Marlon Palangani e Tiago Deoldoto, 11 de Abril de 2009 A linguagem de programação Java proporciona o desenvolvimento aplicações que podem ser executadas

Leia mais

Gerenciamento Básico B de Memória Aula 07

Gerenciamento Básico B de Memória Aula 07 BC1518-Sistemas Operacionais Gerenciamento Básico B de Memória Aula 07 Prof. Marcelo Z. do Nascimento marcelo.nascimento@ufabc.edu.br Roteiro Introdução Espaço de Endereçamento Lógico vs. Físico Estratégias

Leia mais

Sistemas Operativos I

Sistemas Operativos I Gestão da Memória Luis Lino Ferreira / Maria João Viamonte Fevereiro de 2006 Gestão da Memória Gestão de memória? Porquê? Atribuição de instruções e dados à memória Endereços lógicos e físicos Overlays

Leia mais

ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE COMPRESSÃO DE DADOS. Maria Carolina de Souza Santos 1 Orientador: Prof.º Ms.

ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE COMPRESSÃO DE DADOS. Maria Carolina de Souza Santos 1 Orientador: Prof.º Ms. ANÁLISE E IMPLEMENTAÇÃO DE ALGORITMOS DE COMPRESSÃO DE DADOS Maria Carolina de Souza Santos 1 Orientador: Prof.º Ms. Mauricio Duarte 2 Centro Universitário Euripides de Marilia UNIVEM FATEC Faculdade de

Leia mais

FBV - Linguagem de Programação II. Um pouco sobre Java

FBV - Linguagem de Programação II. Um pouco sobre Java FBV - Linguagem de Programação II Um pouco sobre Java História 1992: um grupo de engenheiros da Sun Microsystems desenvolve uma linguagem para pequenos dispositivos, batizada de Oak Desenvolvida com base

Leia mais

3/9/2010. Ligação da UCP com o barramento do. sistema. As funções básicas dos registradores nos permitem classificá-los em duas categorias:

3/9/2010. Ligação da UCP com o barramento do. sistema. As funções básicas dos registradores nos permitem classificá-los em duas categorias: Arquitetura de Computadores Estrutura e Funcionamento da CPU Prof. Marcos Quinet Universidade Federal Fluminense P.U.R.O. Revisão dos conceitos básicos O processador é o componente vital do sistema de

Leia mais

Introdução à Linguagem Java

Introdução à Linguagem Java Introdução à Linguagem Java Histórico: Início da década de 90. Pequeno grupo de projetos da Sun Microsystems, denominado Green. Criar uma nova geração de computadores portáveis, capazes de se comunicar

Leia mais

Experimentos com a memória cache do CPU

Experimentos com a memória cache do CPU Experimentos com a memória cache do CPU Alberto Bueno Júnior & Andre Henrique Serafim Casimiro Setembro de 2010 1 Contents 1 Introdução 3 2 Desvendando o cache 3 2.1 Para que serve o cache?.....................

Leia mais

Estudo comparativo entre tecnologias Java: Applet e JWS.

Estudo comparativo entre tecnologias Java: Applet e JWS. Estudo comparativo entre tecnologias Java: Applet e JWS. Clara Aben-Athar B. Fernandes¹, Carlos Alberto P. Araújo¹ 1 Centro Universitário Luterano de Santarém Comunidade Evangélica Luterana (CEULS/ULBRA)

Leia mais

Linguagem de Programação Introdução a Linguagem Java

Linguagem de Programação Introdução a Linguagem Java Linguagem de Programação Introdução a Linguagem Java Rafael Silva Guimarães Instituto Federal do Espírito Santo Campus Cachoeiro de Itapemirim Definição A linguagem Java foi desenvolvida pela Sun Microsystems,

Leia mais

CAMADA DE REDES. Fabrício de Sousa Pinto

CAMADA DE REDES. Fabrício de Sousa Pinto CAMADA DE REDES Fabrício de Sousa Pinto Introdução 2 Está relacionada a transferência de pacotes da origem para o destino. Pode passar por vários roteadores ao longo do percurso Transmissão fim a fim Para

Leia mais

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários.

Um sistema é constituído de um conjunto de processos que executam seus respectivos códigos do sistema operacional e processos e códigos de usuários. Os sistemas computacionais atuais permitem que diversos programas sejam carregados na memória e executados simultaneamente. Essa evolução tornou necessário um controle maior na divisão de tarefas entre

Leia mais

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos

Roteiro. Sistemas Distribuídos. Sistemas de Arquivos Distribuídos. Sistema de arquivos distribuídos Sistemas Distribuídos Sistemas de Arquivos Distribuídos Roteiro Sistema de arquivos distribuídos Requisitos Arquivos e diretórios Compartilhamento Cache Replicação Estudo de caso: NFS e AFS Sistemas Distribuídos

Leia mais

Balanceamento de Carga

Balanceamento de Carga 40 4. Balanceamento de Carga Pode-se entender por balanceamento de carga uma política a ser adotada para minimizar tanto a ociosidade de utilização de alguns equipamentos quanto a super utilização de outros,

Leia mais

Estudo de Caso 2: Windows Vista

Estudo de Caso 2: Windows Vista Faculdades Integradas de Mineiros Curso de Sistemas de Informação Sistemas Operacionais II Estudo de Caso 2: Windows Vista Grupo 4 Helder / Wagner / Frantyeis Junho/2010 O Windows usa uma estratégia Just-In-Time

Leia mais

Gerência de Memória em Java Parte I: Arquitetura da JVM e algoritmos de coleta de lixo

Gerência de Memória em Java Parte I: Arquitetura da JVM e algoritmos de coleta de lixo Tópicos selecionados de programação em Java Gerência de Memória em Java Parte I: Arquitetura da JVM e algoritmos de coleta de lixo Helder da Rocha Setembro 2005 1 Por que gerenciar memória? Há linguagens

Leia mais

Disciplina: Sistemas Operacionais - CAFW-UFSM Professor: Roberto Franciscatto

Disciplina: Sistemas Operacionais - CAFW-UFSM Professor: Roberto Franciscatto Disciplina: Sistemas Operacionais - CAFW-UFSM Professor: Roberto Franciscatto Introdução Considerações: Recurso caro e escasso; Programas só executam se estiverem na memória principal; Quanto mais processos

Leia mais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais

Notas da Aula 17 - Fundamentos de Sistemas Operacionais Notas da Aula 17 - Fundamentos de Sistemas Operacionais 1. Gerenciamento de Memória: Introdução O gerenciamento de memória é provavelmente a tarefa mais complexa de um sistema operacional multiprogramado.

Leia mais

GERENCIAMENTO DE DISPOSITIVOS

GERENCIAMENTO DE DISPOSITIVOS 2 SISTEMAS OPERACIONAIS: GERENCIAMENTO DE DISPOSITIVOS E ARQUIVOS Introdução à Microinformática Prof. João Paulo Lima Universidade Federal Rural de Pernambuco Departamento de Estatística e Informática

Leia mais

Esta dissertação apresentou duas abordagens para integração entre a linguagem Lua e o Common Language Runtime. O objetivo principal da integração foi

Esta dissertação apresentou duas abordagens para integração entre a linguagem Lua e o Common Language Runtime. O objetivo principal da integração foi 5 Conclusão Esta dissertação apresentou duas abordagens para integração entre a linguagem Lua e o Common Language Runtime. O objetivo principal da integração foi permitir que scripts Lua instanciem e usem

Leia mais

Gerência de Memória RAM em Computadores com Mais de 4GB O sistema Windows x86 (32bits) não tem capacidade de reconhecer, fisicamente, mais que 3,X GB de RAM, a não ser que seja ativado, manualmente, o

Leia mais

Linguagens de Programação

Linguagens de Programação Linguagens de Programação Prof. Miguel Elias Mitre Campista http://www.gta.ufrj.br/~miguel Parte IV Introdução à Programação em C++ (Continuação) Relembrando da Última Aula... Funções Classes de armazenamento

Leia mais

Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java

Análise de desempenho de sistemas distribuídos de grande porte na plataforma Java UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE UNIVERSIDADE FEDERAL DO RIO GRANDE DO NORTE CENTRO DE TECNOLOGIA PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA ELÉTRICA Análise de desempenho de sistemas distribuídos

Leia mais

Alocação dinâmica de memória

Alocação dinâmica de memória Alocação dinâmica de memória Jander Moreira 1 Primeiras palavras Na solução de problemas por meio algoritmos ou programas, é comum surgir a necessidade de manter todo o conjunto de dados a ser processado

Leia mais

Manual de referência do Device Storage Manager

Manual de referência do Device Storage Manager Manual de referência do Device Storage Manager Avisos sobre direitos autorais e marcas comerciais Copyright 2003 Hewlett-Packard Development Company, L.P. É proibida a reprodução, adaptação ou tradução

Leia mais

Como construir um compilador utilizando ferramentas Java

Como construir um compilador utilizando ferramentas Java Como construir um compilador utilizando ferramentas Java p. 1/2 Como construir um compilador utilizando ferramentas Java Aula extra A Máquina Virtual Java Prof. Márcio Delamaro delamaro@icmc.usp.br Como

Leia mais

CA Nimsoft Monitor Snap

CA Nimsoft Monitor Snap CA Nimsoft Monitor Snap Guia de Configuração do Monitoramento da máquina virtual Java jvm_monitor série 1.4 Aviso de copyright do CA Nimsoft Monitor Snap Este sistema de ajuda online (o Sistema ) destina-se

Leia mais

Qualidade de Software

Qualidade de Software Qualidade de Software O software é algo abstrato, pois são as instruções que quando executadas atingem o propósito desejado no sistema computacional. (Algoritmo). As principais características são: Complexidade:

Leia mais

UMA IMPLEMENTAÇÃO EM LINGUAGEM JAVA DE ALGORITMO DE CLASSIFICAÇÃO BASEADO NO MÉTODO DA INSERÇÃO DIRETA

UMA IMPLEMENTAÇÃO EM LINGUAGEM JAVA DE ALGORITMO DE CLASSIFICAÇÃO BASEADO NO MÉTODO DA INSERÇÃO DIRETA UMA IMPLEMENTAÇÃO EM LINGUAGEM JAVA DE ALGORITMO DE CLASSIFICAÇÃO BASEADO NO MÉTODO DA INSERÇÃO DIRETA 1 BIM,Pedro Henrique Marana; 1 RABALDELLI, Diego José Caíres; 1 SOARES, Luis Antonio; 2 TAMAE, Rodrigo

Leia mais

Organização de Computadores

Organização de Computadores Organização de Computadores Marcelo Lobosco DCC/UFJF Avaliando e Compreendendo o Desempenho Aula 09 Agenda Avaliando e Compreendendo o Desempenho Introdução Definindo Desempenho Medindo o Desempenho Desempenho

Leia mais

AULA 16 - Sistema de Arquivos

AULA 16 - Sistema de Arquivos AULA 16 - Sistema de Arquivos Arquivos podem ser vistos como recipientes que contêm dados ou como um grupo de registros correlatos. Os arquivos armazenam informações que serão utilizadas, em geral, por

Leia mais

Java & OpenJDK. Thiago S. Gonzaga. Sun Campus Ambassador thiago.gonzaga@sun.com

Java & OpenJDK. Thiago S. Gonzaga. Sun Campus Ambassador thiago.gonzaga@sun.com Java & OpenJDK Thiago S. Gonzaga Sun Campus Ambassador thiago.gonzaga@sun.com Tópicos Sobre a Sun Microsystems Algumas tecnologias da Sun Linguagem de Programação Ciclo de Desenvolvimento O que é Java?

Leia mais

Computadores de Programação (MAB353)

Computadores de Programação (MAB353) Computadores de Programação (MAB353) Aula 7: 29 de abril de 2010 1 2 Subrotinas Um procedimento ou função é uma subrotina armazenada que executa uma tarefa específica baseada nos parâmetros de entrada

Leia mais

Universidade da Beira Interior Cursos: Engenharia Informática, Matemática /Informática e Ensino da Informática

Universidade da Beira Interior Cursos: Engenharia Informática, Matemática /Informática e Ensino da Informática Programação Orientada a Objectos - 28/29; P. Prata, P. Fazendeiro 2 A tecnologia Java Uma ideia base da linguagem JAVA é a de que um programa em JAVA deve poder ser executado em qualquer tipo de computador

Leia mais

USANDO ALGORITMOS PARA COMPARAR PERFORMANCE DE COMPILADORES DE LINGUAGEM C

USANDO ALGORITMOS PARA COMPARAR PERFORMANCE DE COMPILADORES DE LINGUAGEM C USANDO ALGORITMOS PARA COMPARAR PERFORMANCE DE COMPILADORES DE LINGUAGEM C Using Algorithms to Compare Performance of C Language Compilers Walteno Martins Parreira Júnior, Marcio Oliveira Costa, Paulo

Leia mais

Arquitetura e Sistema de Monitoramento para

Arquitetura e Sistema de Monitoramento para Arquitetura e Sistema de Monitoramento para 1 Computação em Nuvem Privada Mestranda: Shirlei A. de Chaves Orientador: Prof. Dr. Carlos Becker Westphall Colaborador: Rafael B. Uriarte Introdução Computação

Leia mais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais

Arquitetura de Computadores. Introdução aos Sistemas Operacionais Arquitetura de Computadores Introdução aos Sistemas Operacionais O que é um Sistema Operacional? Programa que atua como um intermediário entre um usuário do computador ou um programa e o hardware. Os 4

Leia mais

PADI 2015/16. Aula 1 Introdução à Plataforma.NET

PADI 2015/16. Aula 1 Introdução à Plataforma.NET PADI 2015/16 Aula 1 Introdução à Plataforma.NET 1 Sumário 1. Framework.NET Arquitectura 2. Linguagem C# 2.0 Sintaxe C# vs. Java vs. C++ 3. IDE: MS Visual Studio 2005 ou superior Ferramentas Console/Win

Leia mais

RELAÇÕES ENTRE COMPUTADORES EM DOMÍNIOS WINDOWS NT

RELAÇÕES ENTRE COMPUTADORES EM DOMÍNIOS WINDOWS NT RELAÇÕES ENTRE COMPUTADORES EM DOMÍNIOS WINDOWS NT Resumo Durante o período compreendido entre 1997 e 1998 houve, no CBPF, um aumento significativo do número de ambientes computacionais do tipo grupo de

Leia mais

Unidade 14: Arquiteturas CISC e RISC Prof. Daniel Caetano

Unidade 14: Arquiteturas CISC e RISC Prof. Daniel Caetano Arquitetura e Organização de Computadores 1 Unidade 14: Arquiteturas CISC e RISC Prof. Daniel Caetano Objetivo: Apresentar os conceitos das arquiteturas CISC e RISC, confrontando seus desempenhos. Bibliografia:

Leia mais

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS

GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS GUILHERME STUTZ TÖWS ANIMAÇÃO DE ALGORITMOS Trabalho de graduação do Curso de Ciência da Computação do Setor de Ciências Exatas da Universidade Federal do Paraná. Professor: André Luiz Pires Guedes CURITIBA

Leia mais

5 Mecanismo de seleção de componentes

5 Mecanismo de seleção de componentes Mecanismo de seleção de componentes 50 5 Mecanismo de seleção de componentes O Kaluana Original, apresentado em detalhes no capítulo 3 deste trabalho, é um middleware que facilita a construção de aplicações

Leia mais

Organização de Computadores

Organização de Computadores Organização de Computadores SUMÁRIO Arquitetura e organização de computadores Hardware Software SUMÁRIO Arquitetura e organização de computadores Terminologia básica Hardware Software Arquitetura e organização

Leia mais

ARQUITETURA DE COMPUTADORES - 1866

ARQUITETURA DE COMPUTADORES - 1866 7 Unidade Central de Processamento (UCP): O processador é o componente vital do sistema de computação, responsável pela realização das operações de processamento e de controle, durante a execução de um

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais Gerenciamento de Memória Norton Trevisan Roman Marcelo Morandini Jó Ueyama Apostila baseada nos trabalhos de Kalinka Castelo Branco, Antônio Carlos Sementille, Paula Prata e nas transparências

Leia mais

Informática I. Aula 19. http://www.ic.uff.br/~bianca/informatica1/ Aula 19-20/11/06 1

Informática I. Aula 19. http://www.ic.uff.br/~bianca/informatica1/ Aula 19-20/11/06 1 Informática I Aula 19 http://www.ic.uff.br/~bianca/informatica1/ Aula 19-20/11/06 1 Ementa Histórico dos Computadores Noções de Hardware e Software Microprocessadores Sistemas Numéricos e Representação

Leia mais

Uma comparação de algoritmos e estruturas de dados para armazenamento de dados em sistemas operacionais Palm OS *

Uma comparação de algoritmos e estruturas de dados para armazenamento de dados em sistemas operacionais Palm OS * Uma comparação de algoritmos e estruturas de dados para armazenamento de dados em sistemas operacionais Palm OS * Rogério Celestino dos Santos 1, Rodrigo Otavio Rodrigues Antunes 1* ¹Instituto de Informática

Leia mais

MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R

MINISTÉRIO DA INTEGRAÇÃO NACIONAL SECRETARIA EXECUTIVA DEPARTAMENTO DE GESTÃO ESTRATÉGICA COORDENAÇÃO-GERAL DE TECNOLOGIA DA INFORMAÇÃO ENCARTE R ENCARTE R Estimativa de de Software Estimativa de de Software: Contratação de Serviços de Fábrica de Software Página 1 de 10 SUMÁRIO 1 REFERÊNCIAS... 3 1 INTRODUÇÃO... 3 3.1 ESTIMATIVA PRELIMINAR... 4

Leia mais

2 Atualidade de uma base de dados

2 Atualidade de uma base de dados 2 Atualidade de uma base de dados Manter a atualidade de uma base de dados é um problema que pode ser abordado de diferentes maneiras. Cho e Garcia-Molina [CHO] definem esse problema da seguinte forma:

Leia mais

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert:

BRAlarmExpert. Software para Gerenciamento de Alarmes. BENEFÍCIOS obtidos com a utilização do BRAlarmExpert: BRAlarmExpert Software para Gerenciamento de Alarmes A TriSolutions conta com um produto diferenciado para gerenciamento de alarmes que é totalmente flexível e amigável. O software BRAlarmExpert é uma

Leia mais

Descobrindo o Profiling de

Descobrindo o Profiling de artigo Descobrindo o Profiling de Aplicações Java com JProfiler Aprenda como encontrar problemas de performance na sua aplicação com o JProfiler. Muitas vezes, nos deparamos com problemas de performance

Leia mais

? O SQL SERVER é um sistema de gerenciamento de banco de dados relacional que foi desenvolvido inicialmente pela Microsoft em parceria com a Sybase.

? O SQL SERVER é um sistema de gerenciamento de banco de dados relacional que foi desenvolvido inicialmente pela Microsoft em parceria com a Sybase. ? O SQL SERVER é um sistema de gerenciamento de banco de dados relacional que foi desenvolvido inicialmente pela Microsoft em parceria com a Sybase.? Desde de 1994, a Microsoft lança versões do SQL SERVER

Leia mais

Por dentro do Windows: Gerenciamento de Memória

Por dentro do Windows: Gerenciamento de Memória Por dentro do Windows: Gerenciamento de Memória Rodrigo Strauss http://www.1bit.com. ://www.1bit.com.brbr 1 Definindo Windows Falaremos somente sobre Windows NT NT 3.51 NT 4 Windows 2000 (NT5) Windows

Leia mais

Sistema de Arquivos FAT

Sistema de Arquivos FAT Sistemas Operacionais Sistema de Arquivos FAT Edeyson Andrade Gomes www.edeyson.com.br FAT A FAT é o sistema de arquivos usado pelo MS-DOS e outros sistemas operacionais baseados em Windows para organizar

Leia mais

IBM Security SiteProtector System Guia de Instalação

IBM Security SiteProtector System Guia de Instalação IBM Security IBM Security SiteProtector System Guia de Instalação Versão 3.0 Nota Antes de usar estas informações e o produto suportado por elas, leia as informações em Avisos na página 71. Esta edição

Leia mais

Implementação de Clusters Virtuais em Hosts Windows

Implementação de Clusters Virtuais em Hosts Windows Implementação de Clusters Virtuais em Hosts Windows David Beserra 1, Alexandre Borba 1, Samuel Souto 1, Mariel Andrade 1, Alberto Araújo 1 1 Unidade Acadêmica de Garanhuns Universidade Federal Rural de

Leia mais

Usuários. Aplicativos e programas dos usuários. Kernel gerenciamento de processos, memória, sistema de arquivos, I/O, etc.

Usuários. Aplicativos e programas dos usuários. Kernel gerenciamento de processos, memória, sistema de arquivos, I/O, etc. 1 1.0 Kernel O kernel (núcleo) representa o coração do Sistema Operacional. Atribuições do kernel: - gerenciamento dos arquivos em disco; - inicializar programas e executá-los; - alocar e gerenciar memória

Leia mais

Cadastramento de Computadores. Manual do Usuário

Cadastramento de Computadores. Manual do Usuário Cadastramento de Computadores Manual do Usuário Setembro 2008 ÍNDICE 1. APRESENTAÇÃO 1.1 Conhecendo a solução...03 Segurança pela identificação da máquina...03 2. ADERINDO À SOLUÇÃO e CADASTRANDO COMPUTADORES

Leia mais

Cadastramento de Computadores. Manual do Usuário

Cadastramento de Computadores. Manual do Usuário Cadastramento de Computadores Manual do Usuário Agosto 2006 ÍNDICE 1. APRESENTAÇÃO 1.1 Conhecendo a solução...03 Segurança pela identificação da máquina...03 2. ADERINDO À SOLUÇÃO e CADASTRANDO COMPUTADORES

Leia mais

Gerência de Memória em Java Parte II: Monitoração e configuração da máquina virtual HotSpot

Gerência de Memória em Java Parte II: Monitoração e configuração da máquina virtual HotSpot Tópicos selecionados de programação em Java Gerência de Memória em Java Parte II: Monitoração e configuração da máquina virtual HotSpot Helder da Rocha Setembro 2005 Otimização da JVM HotSpot A HotSpot

Leia mais

BARRAMENTO DO SISTEMA

BARRAMENTO DO SISTEMA BARRAMENTO DO SISTEMA Memória Principal Processador Barramento local Memória cachê/ ponte Barramento de sistema SCSI FireWire Dispositivo gráfico Controlador de vídeo Rede Local Barramento de alta velocidade

Leia mais

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO

Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Conceitos básicos e serviços do Sistema Operacional Prof. Marcos Ribeiro Quinet de Andrade Universidade Federal Fluminense - UFF Pólo Universitário de Rio das Ostras - PURO Tipos de serviço do S.O. O S.O.

Leia mais

Sistemas Operativos. Gestão de memória. Rui Maranhão (rma@fe.up.pt)

Sistemas Operativos. Gestão de memória. Rui Maranhão (rma@fe.up.pt) Sistemas Operativos Gestão de memória Rui Maranhão (rma@fe.up.pt) Gestão de memória idealmente a memória seria grande rápida não volátil contudo, na realidade existem limitações físicas! Portanto... hierarquia

Leia mais

Capítulo 3 Gerenciamento de memória

Capítulo 3 Gerenciamento de memória Sistemas operacionais modernos Terceira edição ANDREW S. TANENBAUM Capítulo 3 Gerenciamento de memória Introdução Programas tendem a se expandir a fim de ocupar toda a memória disponível Programador deseja

Leia mais

Software Pipeline. Sergio Ricardo Souza Leal de Queiroz. IC-Unicamp - RA: 107070 RESUMO 2. SOFTWARE PIPELINE, CONCEITOS 1.

Software Pipeline. Sergio Ricardo Souza Leal de Queiroz. IC-Unicamp - RA: 107070 RESUMO 2. SOFTWARE PIPELINE, CONCEITOS 1. RESUMO Software Pipeline Sergio Ricardo Souza Leal de Queiroz A partir do momento em que se constatou que a evolução dos computadores não estaria mais na velocidade do processador, e sim em projetar máquinas

Leia mais

Vetores. Vetores. Figura 1 Exemplo de vetor com 10 elementos

Vetores. Vetores. Figura 1 Exemplo de vetor com 10 elementos Vetores Nos capítulos anteriores estudamos as opções disponíveis na linguagem C para representar: Números inteiros em diversos intervalos. Números fracionários com várias alternativas de precisão e magnitude.

Leia mais

Projeto de Sistemas de Tempo Real

Projeto de Sistemas de Tempo Real Projeto de Sistemas de Tempo Real Centro de Informática - Universidade Federal de Pernambuco Engenharia da Computação Kiev Gama kiev@cin.ufpe.br Slides elaborados pelo professor Marcio Cornélio O autor

Leia mais

2 Auto-sintonia de Bancos de Dados e Agentes de Software

2 Auto-sintonia de Bancos de Dados e Agentes de Software 2 Auto-sintonia de Bancos de Dados e Agentes de Software A uso da abordagem de agentes de software 1 pode trazer benefícios a áreas de aplicação em que é necessário construir sistemas autônomos, ou seja,

Leia mais

Sistemas Operacionais Aula 14: Sistema de Arquivos. Ezequiel R. Zorzal ezorzal@unifesp.br www.realidadeaumentada.com.br

Sistemas Operacionais Aula 14: Sistema de Arquivos. Ezequiel R. Zorzal ezorzal@unifesp.br www.realidadeaumentada.com.br Sistemas Operacionais Aula 14: Sistema de Arquivos Ezequiel R. Zorzal ezorzal@unifesp.br www.realidadeaumentada.com.br Introdução O sistema de arquivos é a parte mais vísivel do sistema operacional Cria

Leia mais

Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar

Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar Desempenho de um Cluster Virtualizado em Relação a um Cluster Convencional Similar David Beserra 1, Alexandre Borba¹, Samuel Souto 1, Mariel Andrade 1, Alberto Araujo 1 1 Unidade Acadêmica de Garanhuns

Leia mais

Programação Orientada a Objetos

Programação Orientada a Objetos Programação Orientada a Objetos Universidade Católica de Pernambuco Ciência da Computação Prof. Márcio Bueno poonoite@marciobueno.com Fonte: Material da Profª Karina Oliveira Introdução ao Paradigma OO

Leia mais

Gerenciando a memória

Gerenciando a memória Memória da impressora 1 Sua impressora vem com, pelo menos, 64 MB de memória. Para determinar a quantidade de memória instalada atualmente em sua impressora, selecione Imprimir menus no Menu Utilitários.

Leia mais

Arquitetura e Organização de Computadores

Arquitetura e Organização de Computadores Arquitetura e Organização de Computadores Fernando Fonseca Ramos Faculdade de Ciência e Tecnologia de Montes Claros Fundação Educacional Montes Claros 1 Índice 1- Introdução 2- Exemplo de Microarquitetura

Leia mais

SISTEMAS OPERACIONAIS

SISTEMAS OPERACIONAIS SISTEMAS OPERACIONAIS Processos e Threads Andreza Leite andreza.leite@univasf.edu.br Plano de Aula 2 Gerenciamento de Processos Threads Aplicações com múltiplas Threads Concorrência e Compartilhamento

Leia mais

Sistemas Processadores e Periféricos Aula 9 - Revisão

Sistemas Processadores e Periféricos Aula 9 - Revisão Sistemas Processadores e Periféricos Aula 9 - Revisão Prof. Frank Sill Torres DELT Escola de Engenharia UFMG Adaptado a partir dos Slides de Organização de Computadores 2006/02 do professor Leandro Galvão

Leia mais

Introdução a Informática - 1º semestre AULA 02 Prof. André Moraes

Introdução a Informática - 1º semestre AULA 02 Prof. André Moraes Introdução a Informática - 1º semestre AULA 02 Prof. André Moraes 3 MÁQUINAS VIRTUAIS Em nossa aula anterior, fizemos uma breve introdução com uso de máquinas virtuais para emularmos um computador novo

Leia mais

Organização de Computadores 1

Organização de Computadores 1 Organização de Computadores 1 4 SUPORTE AO SISTEMA OPERACIONAL Prof. Luiz Gustavo A. Martins Sistema Operacional (S.O.) Programa responsável por: Gerenciar os recursos do computador. Controlar a execução

Leia mais

CA Nimsoft Monitor. Guia do Probe Ping do Internet Control Message Protocol. icmp série 1.1

CA Nimsoft Monitor. Guia do Probe Ping do Internet Control Message Protocol. icmp série 1.1 CA Nimsoft Monitor Guia do Probe Ping do Internet Control Message Protocol icmp série 1.1 Aviso de copyright do CA Nimsoft Monitor Este sistema de ajuda online (o Sistema ) destina-se somente para fins

Leia mais

Nível 3 Sistema Operacional

Nível 3 Sistema Operacional Nível 3 Sistema Operacional Universidade Tuiuti do Paraná UTP Faculdade de Ciências Exatas - FACET Tecnologia de Análise e Desenvolvimento de Sistemas Organização de Computadores Prof. André Luiz 1 Nível

Leia mais

Programação Estruturada. Programação Estruturada. Idéias Básicas da Programação Estruturada

Programação Estruturada. Programação Estruturada. Idéias Básicas da Programação Estruturada Programação Estruturada Programação Estruturada Paradigmas de Linguagens de Programação As linguagens desse paradigma são muitas vezes chamadas de linguagens convencionais, procedurais ou imperativas.

Leia mais