IFPR Instituto Federal do Paraná. Curso Técnico em Informática GERÊNCIA DE MEMÓRIA. SO Sistemas Operacionais. Professora Elaine Augusto Praça

Transcrição

1 IFPR Instituto Federal do Paraná Curso Técnico em Informática GERÊNCIA DE MEMÓRIA SO Sistemas Operacionais Professora Elaine Augusto Praça MACHADO, Francis B., Arquitetura de Sistemas Operacionais, RJ, LTC, 2007

2 1. Introdução Historicamente, a memória principal (RAM) sempre foi vista como um recurso escasso e caro. Mesmo atualmente com a redução de custo e conseqüente aumento da capacidade de memória principal, seu gerenciamento é um dos fatores + importantes no projeto de SO. Nos SOs multiprogramáveis a gerência de memória se torna crítica devido à necessidade de se maximizar o nº. de usuários/aplicações utilizando eficientemente o espaço da memória principal.

3 2. Funções Básicas Em geral os programas são armazenados em memórias secundárias (HD, fita), por ser um meio não-volátil, abundante e de custo baixo. Como o processador somente executa instruções localizadas na memória principal, o SO deve sempre transferir programas da memória secundária para a memória principal antes de serem executados. Como o tempo de acesso à memória 1ª é muito superior ao tempo de acesso à memória 2ª, o SO deve buscar reduzir o nº. de operações E/S à memória secundária, caso contrário podem ocasionar sérios problemas no desempenho do sistema.

4 2. Funções Básicas A gerência de memória deve tentar manter na memória principal o maior nº. de processos residentes, permitindo maximizar o compartilhamento do processador e demais recursos computacionais. SWAPPING: Mesmo na ausência de espaço livre, o SO deve permitir que novos processos sejam aceitos e executados. Isso é possível através da transferência temporária de processos residentes na memória principal p\ a memória 2ª, liberando espaço p\ novos processos. Outra preocupação na gerência de memória é permitir a execução de programas que sejam maiores que a memória física disponível, implementada através de técnicas de OVERLAY e a MEMÓRIA VIRTUAL.

5 2. Funções Básicas Na multiprogramação, o SO deve proteger áreas de memória ocupadas por cada processo, além da área onde reside o próprio SO. Caso um programa tente realizar algum acesso indevido à memória, o SO de alguma forma deve impedí-lo. Apesar de a gerência de memória garantir a proteção de áreas de memória, mecanismos de compartilhamento devem ser oferecidos p\ que diferentes processos possam trocar dados de forma protegida.

6 3. Alocação Contígua Simples Foi implementada nos primeiros SOs, porém ainda está presente em alguns SO monoprogramáveis. Nesse tipo de organização, a memória principal é subdividida em 2 áreas: Dessa forma o programador deve desenvolver suas aplicações preocupando-se apenas em não ultrapassar o espaço de memória disponível, ou seja, a diferença entre o tamanho total da memória principal e a área já ocupada pelo SO.

7 3. Alocação Contígua Simples Nesse esquema, o usuário tem controle sobre toda a memória principal, podendo ter acesso a qualquer posição da memória, inclusive da área do SO. Dessa forma o programador deve desenvolver suas aplicações preocupando-se apenas em não ultrapassar o espaço de memória disponível, ou seja, a diferença entre o tamanho total da memória principal e a área já ocupada pelo SO. Para proteger o SO desse tipo de acesso, que pode ser intencional ou não, alguns SOs implementam uma proteção através de um registrador que delimita as áreas do SO e do usuário.

8 3. Alocação Contígua Simples Dessa forma, sempre que um programa faz referência a um endereço na memória, o SO verifica se o endereço está dentro dos limites permitidos. Caso contrário o programa é cancelado e uma mensagem de erro é gerada, indicando que houve uma violação no acesso à memória principal.

9 3. Alocação Contígua Simples Apesar da fácil implementação e do código reduzido, a alocação contígua não permite a utilização eficiente dos recursos computacionais, pois apenas um usuário pode dispor desses recursos. Em relação à memória principal, caso o programa do usuário não a preencha totalmente, haverá um espaço livre na memória, ou seja, sem utilização.

10 4. Técnica de OVERLAY Na alocação contígua simples, todos os programas estão limitados ao tamanho da área de memória principal disponível para o usuário. Uma solução encontrada para o problema é dividir o programa em módulos, de forma que seja possível a execução independente de cada módulo, utilizando uma mesma área de memória. Esta é a técnica de OVERLAY. EX.: Considere um programa que tenha 3 módulos: um principal, um de cadastramento e outro de impressão, sendo os módulos de cadastro\impressão independentes. A independência do código significa que quando um módulo estiver na memória para execução o outro não precisa necessariamente estar presente.

11 4. Técnica de OVERLAY O módulo principal é o comum aos 2 módulos, logo deve permanecer na memória durante todo o tempo da execução do programa. A memória é insuficiente p\ armazenar todo o programa. A técnica de overlay utiliza uma área de memória comum, onde os módulos de cadastramento e impressão poderão compartilhar a mesma área de memória (área de overlay)

12 4. Técnica de OVERLAY Sempre que 1 dos 2 módulos for referenciado pelo módulo principal, o módulo será carregado da memória secundária (HD) para a área de overlay. Quando é referenciado um módulo que já esteja na área de overlay, a carga não é realizada; caso contrário o novo módulo irá sobrepor-se ao que já estiver na memória

13 4. Técnica de OVERLAY A definição das áreas de overlay é função do programador, através dos comandos específicos da linguagem de programação utilizada. O tamanho de uma área de overlay é estabelecido a partir do tamanho do maior módulo. Ex.: se o módulo de cadastramento tem 4 Kb e o módulo de impressão tem 2 Kb, a área de overlay deverá ter o tamanho do maior módulo, ou seja, 4 Kb. A técnica de overlay tem a vantagem de permitir ao programador expandir os limites da memória principal. A utilização dessa técnica exige muito cuidado, pois pode trazer implicações tanto na sua manutenção quanto no desempenho das aplicações, devido à possibilidade de transferência excessiva dos módulos entre a memória principal e secundária.

14 5. Alocação Particionada Os SOs evoluíram no sentido de proporcionar melhor aproveitamento dos recursos disponíveis. Nos SOs monoprogramáveis o UCP permanece grande parte do tempo ocioso e a memória principal é subutilizada. Os SOs multiprogramáveis já são muito mais eficientes no uso do UCP, necessitando assim, que diversos programas estejam na memória principal ao mesmo tempo e que novas formas de gerência de memória sejam implementadas.

15 5.1 Alocação Particionada Estática/Fixa Nos primeiros SOs multiprogramáveis, a memória era dividida em pedaços de tamanho fixo, chamadas partições. O tamanho das partições, estabelecido na fase de inicialização do sistema, era definido em função do tamanho dos programas que executariam no ambiente. Sempre que fosse necessária a alteração do tamanho de uma partição, o sistema deveria ser desativado e reinicializado com uma nova configuração.

16 5.1 Alocação Particionada Estática Inicialmente, os programas só podiam ser carregados e executados em apenas uma partição específica, mesmo se outras estivessem disponíveis. Essa limitação se devia aos compiladores e montadores que geravam apenas código absoluto, originando então a ALOCAÇÃO PARTICIONADA ESTÁTICA ABSOLUTA.

17 5.1 Alocação Particionada Estática Com a evolução dos compiladores, loaders, montadores e linkers, o código gerado deixou de ser absoluto e passou a ser RELOCÁVEL, onde todas as referências a endereços nos programas são relativas ao início do código e não a endereços físicos de memória. Desta forma os programas puderam ser executados a partir de qualquer partição. Quando o programa é carregado, o loader calcula todos os endereços a partir da posição inicial onde o programa foi alocado. Caso os programas A e B terminassem, o programa E poderia ser executado em qualquer uma 1 das 2 partições, denominada ALOCAÇÃO PARTICIONADA ESTÁTICA RELOCÁVEL.

18 5.1 Alocação Particionada Estática Nesse esquema de ALOCAÇÃO PARTICIONADA ESTÁTICA RELOCÁVEL o controle sobre quais partições estão alocadas, a gerência de memória mantém uma tabela com o endereço inicial de cada partição, seu tamanho e o status (em uso ou livre). Sempre que um programa é carregado p\ a memória, o SO percorre a tabela, na tentativa de localizar uma partição livre onde o programa possa ser carregado.

19 5.1 Alocação Particionada Estática Nesse esquema de alocação de memória a proteção baseia-se em 2 registradores que delimitam a partição (início e fim) onde o programa está sendo executado. Caso o programa tente acessar uma posição de memória fora dos limites definidos pelos registradores, ele é interrompido e uma mensagem de violação de memória é gerado pelo SO. Tanto nos SO de alocação absoluta quanto nos de alocação RELOCÁVEL, os programas, normalmente não preenchem totalmente as partições onde são carregados.

20 5.1 Alocação Particionada Estática Ex.: os programas C-A-E não ocupam integralmente o espaços de suas partições, deixando 1Kb, 3Kb e 5Kb de área livre respectivamente, pois a alocação é fixa. Esse problema, decorrente da alocação fixa das partições, é conhecido como FRAGMENTAÇÃO INTERNA.

21 5.2 Alocação Particionada Dinâmica/Variável Aqui foi eliminado o conceito de partições de tamanho fixo, onde cada programa utilizaria o espaço necessário, tornando essa área a sua partição. Nesse caso não há fragmentação interna, pois cada programa utiliza apenas o necessário.

22 5.2 Alocação Particionada Dinâmica/Variável Em contrapartida, há outro problema: outro tipo de fragmentação começará a ocorrer na medida em que os programas forem terminando e deixando espaços cada vez menores na memória, não permitindo o ingresso de novos programas. Ex.: mesmo existindo 12 Kb livres na memória, o programa D que necessita de 6 Kb de espaço, não poderá ser carregado para execução, pois esse espaço não está disposto contiguamente, gerando FRAGMENTAÇÃO EXTERNA

23 5.2 Alocação Particionada Dinâmica/Variável Há 2 soluções p\ o problema da fragmentação externa da memória principal: 1º) conforme os programas terminam apenas os espaços livres adjacentes são reunidos, produzindo áreas livres de tamanho maior.

24 5.2 Alocação Particionada Dinâmica/Variável Há 2 soluções p\ o problema da fragmentação externa da memória principal: 2º) conforme os programas terminam é feita uma realocação de todas as partições ocupadas, eliminando todos os espaços vazios entre elas e criando uma única área contígua livre.

25 5.2 Alocação Particionada Dinâmica/Variável Para que esse processo de realocação seja possível, é necessário que o SO tenha a capacidade de mover os diversos programas na memória principal, ou seja, fazer a realocação dinâmica. Esse mecanismo de compactação, também conhecido por alocação particionada dinâmica com realocação, reduz muito o problema de fragmentação, porém a complexidade do seu algoritmo e o consumo de recursos do SO, como UCP e área em disco, podem torná-lo inviável.

26 5.3 Estratégias de Alocação de Partição Os SOs implementam, basicamente 3 estratégias para determinar em qual área livre um programa será carregado p\ execução, onde estas estratégias tentam diminuir ou evitar o problema de fragmentação externa. A melhor estratégia a ser adotada depende de uma série de fatores, sendo o + importante o tamanho dos programas processados no ambiente. Independente do algoritmo utilizado, o SO possui uma lista de áreas livres, com o endereço e o tamanho de cada área.

27 5.3 Estratégias de Alocação de Partição 1ª) BEST-FIT: a melhor partição é escolhida, ou seja, aquela em que o programa deixa o menor espaço sem utilização. Nesse algoritmo, a lista de áreas livres está ordenada por tamanho, diminuindo o tempo de busca por uma área desocupada. Uma grande desvantagem é conseqüência do próprio algoritmo. Como ele deixa a menor área livre, a tendência é que cada vez mais a memória fique com pequenas áreas não contíguas, aumentando o problema da fragmentação.

28 5.3 Estratégias de Alocação de Partição 2ª) WORST-FIT: a pior partição é a escolhida, ou seja, aquela em que o programa deixa o maior espaço sem utilização. Apesar de utilizar maiores partições, a técnica deixa espaços livres maiores que permitem a um maior nº. de programas utilizar a memória, diminuindo o problema da fragmentação.

29 5.3 Estratégias de Alocação de Partição 3ª) FIRST-FIT: a primeira partição livre de tamanho suficiente p\ carregar o programa é escolhido. Nesse algoritmo a lista de áreas livres está ordenado por endereços crescentemente. Como o método tenta 1º utilizar as áreas livres de endereços mais baixos há uma grande chance de se obter uma grande partição livre nos endereços de memória mais altos.

30 6. SWAPPING Mesmo com o aumento da eficiência da multiprogramação e da gerencia de memória, muitas vezes um programa não podia ser executado por falta de uma partição livre disponível. A técnica de SWAPPING veio para contornar o problema da insuficiência de memória principal. O swapping é uma técnica aplicada à gerência de memória para programas que esperam por memória livre para serem executados.

31 6. SWAPPING SWAP OUT Nesta situação, o SO escolhe um processo residente, que é transferido da memória principal p\ a memória secundária (swap out), geralmente o HD.

32 6. SWAPPING SWAP IN Posteriormente, o processo é carregado de volta da memória secundária para a memória principal (swap in) e pode continuar a ser executado normalmente, como se nada tivesse ocorrido.

33 6. SWAPPING O algoritmo de escolha do processo a ser retirado da memória principal deve priorizar aquele com menos chances de ser escalonado para evitar o swapping desnecessário de um processo que será executado logo em seguida. Os processos retirados da memória estão geralmente no estado de espera, mas ainda há a possibilidade de um processo no estado de pronto também ser selecionado para swapping. Os processos no estado de espera ou ponto quando fora de memória são ditos não-residentes (outswapped).

34 6. SWAPPING O conceito de swapping permite um maior compartilhamento da memória principal e consequentemente, uma maior utilização dos recursos do sistema computacional. Seu maior problema é o elevado custo das operações E\S (swap in\out). Em momentos em que há pouca memória disponível, o SO pode ficar quase que dedicado à realização de swapping, deixando de executar outras tarefas e impedindo a execução dos demais processos residentes. Essa situação é denominada THRASHING, e é considerada um problema crítico na gerencia de memória dos SOs.