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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

A memória é um recurso fundamental e de extrema importância para a operação de qualquer Sistema Computacional; A memória trata-se de uma grande

A memória é um recurso fundamental e de extrema importância para a operação de qualquer Sistema Computacional; A memória trata-se de uma grande A memória é um recurso fundamental e de extrema importância para a operação de qualquer Sistema Computacional; A memória trata-se de uma grande região de armazenamento formada por bytes ou palavras, cada

Leia mais

José Benedito Lopes Junior ¹, Marcello Erick Bonfim 2

José Benedito Lopes Junior ¹, Marcello Erick Bonfim 2 ISBN 978-85-61091-05-7 Encontro Internacional de Produção Científica Cesumar 27 a 30 de outubro de 2009 Definição de uma tecnologia de implementação e do repositório de dados para a criação da ferramenta

Leia mais

Visão Geral de Sistemas Operacionais

Visão Geral de Sistemas Operacionais Visão Geral de Sistemas Operacionais Sumário Um sistema operacional é um intermediário entre usuários e o hardware do computador. Desta forma, o usuário pode executar programas de forma conveniente e eficiente.

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

O que é RAID? Tipos de RAID:

O que é RAID? Tipos de RAID: O que é RAID? RAID é a sigla para Redundant Array of Independent Disks. É um conjunto de HD's que funcionam como se fosse um só, isso quer dizer que permite uma tolerância alta contra falhas, pois se um

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

? 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

ISO/IEC 12207: Gerência de Configuração

ISO/IEC 12207: Gerência de Configuração ISO/IEC 12207: Gerência de Configuração Durante o processo de desenvolvimento de um software, é produzida uma grande quantidade de itens de informação que podem ser alterados durante o processo Para que

Leia mais

2 Controle de Congestionamento do TCP

2 Controle de Congestionamento do TCP 2 Controle de Congestionamento do TCP 17 2 Controle de Congestionamento do TCP A principal causa de descarte de pacotes na rede é o congestionamento. Um estudo detalhado dos mecanismos de controle de congestionamento

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

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

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

11 Conclusão. 11.1 Descobertas

11 Conclusão. 11.1 Descobertas 97 11 Conclusão 11.1 Descobertas Nesse trabalho apresentamos o McCloud Service Framework, um arcabouço para implementação de serviços baseados na Simulação de Monte Carlo na nuvem, disponibilizamos duas

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

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

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

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

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP)

Hardware (Nível 0) Organização. Interface de Máquina (IM) Interface Interna de Microprogramação (IIMP) Hardware (Nível 0) Organização O AS/400 isola os usuários das características do hardware através de uma arquitetura de camadas. Vários modelos da família AS/400 de computadores de médio porte estão disponíveis,

Leia mais

4 Estrutura do Sistema Operacional. 4.1 - Kernel

4 Estrutura do Sistema Operacional. 4.1 - Kernel 1 4 Estrutura do Sistema Operacional 4.1 - Kernel O kernel é o núcleo do sistema operacional, sendo responsável direto por controlar tudo ao seu redor. Desde os dispositivos usuais, como unidades de disco,

Leia mais

Sistemas Operacionais

Sistemas Operacionais Sistemas Operacionais SISTEMAS DE ARQUIVOS MACHADO/MAIA: CAPÍTULO 11 Prof. Pedro Luís Antonelli Anhanguera Educacional SISTEMAS DE ARQUIVOS - INTRODUÇÃO O armazenamento e a recuperação de informações é

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

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

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

Admistração de Redes de Computadores (ARC)

Admistração de Redes de Computadores (ARC) Admistração de Redes de Computadores (ARC) Instituto Federal de Educação, Ciência e Tecnologia de Santa Catarina - Campus São José Prof. Glauco Cardozo glauco.cardozo@ifsc.edu.br RAID é a sigla para Redundant

Leia mais

William Stallings Arquitetura e Organização de Computadores 8 a Edição

William Stallings Arquitetura e Organização de Computadores 8 a Edição William Stallings Arquitetura e Organização de Computadores 8 a Edição Capítulo 7 Entrada/saída Os textos nestas caixas foram adicionados pelo Prof. Joubert slide 1 Problemas de entrada/saída Grande variedade

Leia mais

Manual de boas práticas Correio Eletrônico

Manual de boas práticas Correio Eletrônico Superintendência de Tecnologia da Informação Gerência de Infraestrutura Tecnológica Gerência Técnica de Suporte e Infraestrutura Manual de boas práticas Correio Eletrônico VERSÃO: 0.2 DATA DE REVISÃO:

Leia mais

Análise de Desempenho de um SGBD para Aglomerado de Computadores

Análise de Desempenho de um SGBD para Aglomerado de Computadores Análise de Desempenho de um SGBD para Aglomerado de Computadores Diego Luís Kreutz, Gabriela Jacques da Silva, Hélio Antônio Miranda da Silva, João Carlos Damasceno Lima Curso de Ciência da Computação

Leia mais

XDOC. Solução otimizada para armazenamento e recuperação de documentos

XDOC. Solução otimizada para armazenamento e recuperação de documentos XDOC Solução otimizada para armazenamento e recuperação de documentos ObJetivo Principal O Que você ACHA De ter Disponível Online todos OS Documentos emitidos por SUA empresa em UMA intranet OU Mesmo NA

Leia mais

DEPARTAMENTO DE ENGENHARIA INFORMÁTICA FACULDADE DE CIÊNCIAS E TECNOLOGIA DA UNIVERSIDADE DE COIMBRA

DEPARTAMENTO DE ENGENHARIA INFORMÁTICA FACULDADE DE CIÊNCIAS E TECNOLOGIA DA UNIVERSIDADE DE COIMBRA DEPARTAMENTO DE ENGENHARIA INFORMÁTICA FACULDADE DE CIÊNCIAS E TECNOLOGIA DA UNIVERSIDADE DE COIMBRA Sistemas Operativos 2003/2004 Trabalho Prático #2 -- Programação em C com ponteiros -- Objectivos Familiarização

Leia mais

AULA4: PROCESSADORES. Figura 1 Processadores Intel e AMD.

AULA4: PROCESSADORES. Figura 1 Processadores Intel e AMD. AULA4: PROCESSADORES 1. OBJETIVO Figura 1 Processadores Intel e AMD. Conhecer as funcionalidades dos processadores nos computadores trabalhando suas principais características e aplicações. 2. INTRODUÇÃO

Leia mais

Fundamentos de Sistemas Operacionais. Sistema de Arquivos. Prof. Edwar Saliba Júnior Março de 2007. Unidade 03-002 Sistemas de Arquivos

Fundamentos de Sistemas Operacionais. Sistema de Arquivos. Prof. Edwar Saliba Júnior Março de 2007. Unidade 03-002 Sistemas de Arquivos Sistema de Arquivos Prof. Edwar Saliba Júnior Março de 2007 1 Objetivos Facilitar o acesso dos usuários ao conteúdo dos arquivos; Prover uma forma uniforme de manipulação de arquivos, independente dos

Leia mais

FAT32 ou NTFS, qual o melhor?

FAT32 ou NTFS, qual o melhor? FAT32 ou NTFS, qual o melhor? Entenda quais as principais diferenças entre eles e qual a melhor escolha O que é um sistema de arquivos? O conceito mais importante sobre este assunto, sem sombra de dúvidas,

Leia mais

ESTRUTURA INTERNA DO SISTEMA ESTRUTURA GERAL DO SGBD. Desempenho do BD ÙSatisfação do usuário. A performance do sistema depende:

ESTRUTURA INTERNA DO SISTEMA ESTRUTURA GERAL DO SGBD. Desempenho do BD ÙSatisfação do usuário. A performance do sistema depende: ESTRUTURA INTERNA DO SISTEMA ESTRUTURA GERAL DO SGBD Desempenho do BD ÙSatisfação do usuário USUÁRIO A performance do sistema depende: da eficiência das estruturas de dados utilizadas; como o sistema opera

Leia mais

Sumário 1. SOBRE O NFGoiana DESKTOP... 3 1.1. Apresentação... 3 1.2. Informações do sistema... 3 1.3. Acessando o NFGoiana Desktop... 3 1.4.

Sumário 1. SOBRE O NFGoiana DESKTOP... 3 1.1. Apresentação... 3 1.2. Informações do sistema... 3 1.3. Acessando o NFGoiana Desktop... 3 1.4. 1 Sumário 1. SOBRE O NFGoiana DESKTOP... 3 1.1. Apresentação... 3 1.2. Informações do sistema... 3 1.3. Acessando o NFGoiana Desktop... 3 1.4. Interface do sistema... 4 1.4.1. Janela Principal... 4 1.5.

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

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

4 Arquitetura básica de um analisador de elementos de redes

4 Arquitetura básica de um analisador de elementos de redes 4 Arquitetura básica de um analisador de elementos de redes Neste capítulo é apresentado o desenvolvimento de um dispositivo analisador de redes e de elementos de redes, utilizando tecnologia FPGA. Conforme

Leia mais

1 REQUISITOS BÁSICOS PARA INSTALAR O SMS PC REMOTO

1 REQUISITOS BÁSICOS PARA INSTALAR O SMS PC REMOTO 1 ÍNDICE 1 REQUISITOS BÁSICOS PARA INSTALAR O SMS PC REMOTO... 3 1.1 REQUISITOS BASICOS DE SOFTWARE... 3 1.2 REQUISITOS BASICOS DE HARDWARE... 3 2 EXECUTANDO O INSTALADOR... 3 2.1 PASSO 01... 3 2.2 PASSO

Leia mais

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br

Java. Marcio de Carvalho Victorino www.dominandoti.eng.br Java Marcio de Carvalho Victorino www.dominandoti.eng.br 3. Considere as instruções Java abaixo: int cont1 = 3; int cont2 = 2; int cont3 = 1; cont1 += cont3++; cont1 -= --cont2; cont3 = cont2++; Após a

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

Sistema Operacional. Processo e Threads. Prof. Dr. Márcio Andrey Teixeira Sistemas Operacionais

Sistema Operacional. Processo e Threads. Prof. Dr. Márcio Andrey Teixeira Sistemas Operacionais Sistema Operacional Processo e Threads Introdução a Processos Todos os computadores modernos são capazes de fazer várias coisas ao mesmo tempo. Enquanto executa um programa do usuário, um computador pode

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

Infraestrutura de Hardware. Memória Virtual

Infraestrutura de Hardware. Memória Virtual Infraestrutura de Hardware Memória Virtual Perguntas que Devem ser Respondidas ao Final do Curso Como um programa escrito em uma linguagem de alto nível é entendido e executado pelo HW? Qual é a interface

Leia mais

CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines

CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines CloudNet: dynamic pooling of cloud resources by live WAN migration of virtual machines Timothy Wood, Prashant Shenoy, K.K. Ramakrishnan, Jacobus Van der Merwe VEE '11 Proceedings of the 7th ACM SIGPLAN/SIGOPS

Leia mais

GUIA DE BOAS PRÁTICAS

GUIA DE BOAS PRÁTICAS GUIA DE BOAS PRÁTICAS Sumário Requisitos para um bom funcionamento...3 Menu Configurações...7 Como otimizar o uso da sua cota...10 Monitorando o backup...8 Manutenção de arquivos...12 www.upbackup.com.br

Leia mais

Gerência de Processador

Gerência de Processador Gerência de Processador Prof. Edwar Saliba Júnior Junho de 2009 Unidade 03-003 Gerência de Processador 1 Introdução Com o surgimento dos sistemas multiprogramáveis, onde múltiplos processos poderiam permanecer

Leia mais

Memória - Gerenciamento. Sistemas Operacionais - Professor Machado

Memória - Gerenciamento. Sistemas Operacionais - Professor Machado Memória - Gerenciamento Sistemas Operacionais - Professor Machado 1 Partes físicas associadas à memória Memória RAM Memória ROM Cache MMU (Memory Management Unit) Processador Tabela de Páginas TLB 2 Conceitos

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

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

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

Árvore B UNITINS ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 3º PERÍODO 43

Árvore B UNITINS ANÁLISE E DESENVOLVIMENTO DE SISTEMAS 3º PERÍODO 43 AULA A 3 ESTRUTURA RA DE DADOS Árvore B Esperamos que, ao final desta aula, você seja capaz de: identificar as vantagens da árvore B em relação às árvores binária de busca e AVL; conhecer as funções de

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

Orientação a Objetos

Orientação a Objetos 1. Domínio e Aplicação Orientação a Objetos Um domínio é composto pelas entidades, informações e processos relacionados a um determinado contexto. Uma aplicação pode ser desenvolvida para automatizar ou

Leia mais

Desenvolvimento de um Simulador de Gerenciamento de Memória

Desenvolvimento de um Simulador de Gerenciamento de Memória Desenvolvimento de um Simulador de Gerenciamento de Memória Ricardo Mendes do Nascimento. Ciência da Computação Universidade Regional Integrada do Alto Uruguai e das Missões (URI) Santo Ângelo RS Brasil

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

VirtuOS vrs. 4.00 para usuários da vrs. 3.01a R.10

VirtuOS vrs. 4.00 para usuários da vrs. 3.01a R.10 VirtuOS vrs. 4.00 para usuários da vrs. 3.01a R.10 Este documento resume as principais diferenças entre a vrs. 4.00 em relação à vrs. 3.01a R.10 do Sistema VirtuOS e se destina aos usuários que dela estão

Leia mais

Roteamento em Redes de Computadores

Roteamento em Redes de Computadores Roteamento em Redes de Computadores José Marcos Câmara Brito INATEL - Instituto Nacional de Telecomunicações INATEL - Instituto Nacional de Telecomunicações 01/08/00 1 Introdução Objetivo Tipos de rede

Leia mais

Aspectos técnicos do desenvolvimento baseado em componentes

Aspectos técnicos do desenvolvimento baseado em componentes Aspectos técnicos do desenvolvimento baseado em componentes Um novo processo de desenvolvimento O uso de componentes traz mudanças no processo de desenvolvimento Além de desenvolver um produto, queremos

Leia mais

7 Processos. 7.1 Introdução

7 Processos. 7.1 Introdução 1 7 Processos 7.1 Introdução O conceito de processo é a base para a implementação de um sistema multiprogramável. O processador é projetado apenas para executar instruções, não se importando com qual programa

Leia mais

Sistema Operacional Unidade 4.2 - Instalando o Ubuntu Virtualizado

Sistema Operacional Unidade 4.2 - Instalando o Ubuntu Virtualizado Sistema Operacional Unidade 4.2 - Instalando o Ubuntu Virtualizado Curso Técnico em Informática SUMÁRIO INTRODUÇÃO... 3 CRIAÇÃO DA MÁQUINA VIRTUAL... 3 Mas o que é virtualização?... 3 Instalando o VirtualBox...

Leia mais

TRABALHO COM GRANDES MONTAGENS

TRABALHO COM GRANDES MONTAGENS Texto Técnico 005/2013 TRABALHO COM GRANDES MONTAGENS Parte 05 0 Vamos finalizar o tema Trabalho com Grandes Montagens apresentando os melhores recursos e configurações de hardware para otimizar a abertura

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

28/9/2010. Unidade de Controle Funcionamento e Implementação

28/9/2010. Unidade de Controle Funcionamento e Implementação Arquitetura de Computadores Unidade de Controle Funcionamento e Implementação Prof. Marcos Quinet Universidade Federal Fluminense P.U.R.O. Operação da Unidade de Controle Unidade de controle: parte do

Leia mais

Aula 1 Windows Server 2003 Visão Geral

Aula 1 Windows Server 2003 Visão Geral Aula 1 Windows Server 2003 Visão Geral Windows 2003 Server Introdução Nessa Aula: É apresentada uma visão rápida e geral do Windows Server 2003. O Foco a partir da próxima aula, será no serviço de Diretórios

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

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com

Sistemas Operacionais Aula 03: Estruturas dos SOs. Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com Sistemas Operacionais Aula 03: Estruturas dos SOs Ezequiel R. Zorzal ezorzal@unifesp.br www.ezequielzorzal.com OBJETIVOS Descrever os serviços que um sistema operacional oferece aos usuários e outros sistemas

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

Notas da Aula 15 - Fundamentos de Sistemas Operacionais

Notas da Aula 15 - Fundamentos de Sistemas Operacionais Notas da Aula 15 - Fundamentos de Sistemas Operacionais 1. Software de Entrada e Saída: Visão Geral Uma das tarefas do Sistema Operacional é simplificar o acesso aos dispositivos de hardware pelos processos

Leia mais