Recuperando a memória de aplicativos com o estilo Metro

Os sistemas operacionais modernos têm uma visão diferenciada sobre os recursos em um sistema. Independentemente do fator forma, é importante que um sistema operacional gerencie a utilização dos recursos de maneira mais eficiente do que no passado. Atualmente, é muito fácil que um único processo consuma os recursos disponíveis (memória, CPU, E/S de disco), mesmo quando isso não melhora o desempenho geral para os usuários finais. O papel principal de um sistema operacional é equilibrar os recurso e garantir que você possa completar todas as tarefas que deseja realizar no seu PC. Grande parte do controle manual presente na maioria das implementações de sistemas operacionais foi desenvolvido para se adaptar a softwares errantes - softwares que atingem um estado no qual o consumo de recursos não tem controle. Mesmo que o software seja mal-intencionado, o que geralmente é o caso, a capacidade de desenvolvimento de softwares bem-comportados estava limitada pela complexidade das APIs de alocação de recursos. A API moderna configurada em um WinRT foi desenvolvida por programadores para que eles pudessem criar com mais facilidade softwares que concluíssem as tarefas sem “ocupar completamente” o seu PC. Isso é algo que torna os fatores de forma do PC e os softwares mais eficientes.

Nesta postagem, o gerente de programas de grupo Bill Karagounis de nossa equipe de funções básicas detalha o que há por trás dos esforços para recuperar a memória mesmo quando os aplicativos são suspensos e como isso tudo acontece sem que os desenvolvedores precisem se preocupar.
--Steven

---

Postagens anteriores do blog já discutiram o modelo de aplicativos com o estilo Metro usando o Tempo de Execução do Windows. Um atributo importante deste modelo de aplicativo é que os aplicativos são suspensos quando não são mais visíveis ao usuário. Suspender aplicativos com o estilo Metro no plano de fundo é algo bom, pois protege a CPU de outros aplicativos e garante que os aplicativos do plano de fundo não realizem atividades que poderão consumir recursos, melhorando assim a vida útil da bateria e aumentando a capacidade de resposta. Isso está descrito em detalhes na postagem do blog de Sharif Farag e Ben Srour, Aumentando a eficiência no consumo de energia pelos aplicativos.

Mas e a respeito da memória que esses aplicativos utilizam quando são suspensos? Mais cedo, destacamos que, normalmente, o sistema operacional gerenciará isso e os seus outros processos não sentirão a pressão da memória porque alguns processos serão suspensos. Isso foi levado em consideração durante o desenvolvimento. No entanto, sabemos que alguns de vocês ainda estão curiosos sobre como isso funcionará.

Desde o Windows 8 Consumer Preview, sempre que o Windows detecta uma pressão de memória no sistema, ele redefine quase toda a memória que os aplicativos com o estilo Metro suspensos normalmente utilizariam. O Windows 8 é capaz de recuperar a memória sem ter de terminar um aplicativo.

Baixe este vídeo para vê-lo no seu media player favorito:
MP4 de alta qualidade | MP4 de qualidade inferior

Memória, capacidade de resposta e aplicativos com o estilo Metro

Para qualquer tipo de aplicativo (estilo Metro ou da área de trabalho), o Windows tenta regular as alocações da memória física para beneficiar aquele aplicativo, independentemente da solicitação de memória que ele tenha feito. O Windows sempre se comportou dessa maneira para manter a memória disponível, antecipando a necessidade futura de memória do aplicativo. O Windows é cuidados ao alocar a memória física para um aplicativo somente quando um aplicativo tenta acessá-la, mesmo que o aplicativo já a tenha 'alocado' mais cedo. O Windows também redefinirá partes da memória de um aplicativo se as páginas da memória não tiverem sido acessadas em muito tempo.

É importante entender que nossa meta não é negar um processo de solicitação de memória, mas atrasar a alocação da memória física o maior tempo possível (até o momento em que o usuário de fato toque no aplicativo) porque, com tantos recursos, há uma tendência do software em sobrealocar a memória. O sistema operacional é o lugar no qual todas essas solicitações se reúnem e também onde estão as informações que revelam que atender a todas as solicitações de alocação iria, por fim, enfraquecer todos os processos. Os aplicativos não apenas trabalhariam de maneira incompleta, mas o sistema ficaria praticamente bloqueado. Isso ocorre até mesmo quando a memória é virtual. Em vez de esgotar a RAM, o seu PC simplesmente alternaria páginas para dentro e fora do disco.

A memória física oferecida para um processo a qualquer momento é referida como o “conjunto de trabalho” do processo. Um conjunto de trabalho particular representa a memória física que é exclusiva para um processo. Os processos também acessam outras páginas da memória física que são “compartilhadas” e aos quais muitos processos podem se referir. Quando você observa a exibição dos processos no Gerenciador de Tarefas, a memória para um processo específico também é seu conjunto de trabalho particular no momento. OBSERVAÇÃO: Para simplificar, quando eu me refiro a “conjunto de trabalho” neste blog, quero dizer “conjunto de trabalho particular”.

Quando o sistema começa a ficar com pouca memória disponível, o sistema operacional procurará entre todos os processos pelas páginas da memória física que poderá redefinir para satisfazer outras necessidades no sistema, mesmo que se redefina a memória quando necessário. Para aplicativos da área de trabalho, o Windows tentará manter as páginas mais importantes (frequentemente acessadas) da memória no conjunto de trabalho do aplicativo; isso porque os aplicativos da área de trabalho esperam ser capazes de executar códigos a qualquer momento, mesmo quando eles estão no plano de fundo. No entanto, trate-se de um difícil equilibro: se muitas páginas da memória tiverem sido removidas do aplicativo da área de trabalho, poderiam afetar a capacidade de resposta do aplicativo devido ao E/S de disco adicional (à medida que o aplicativo tenta acessar a memória que foi paginada para o disco em segundo plano).

Para se aprofundar no gerenciamento de memória do Windows, veja “Mysteries of Windows Memory Management Revealed” (Mistérios do gerenciamento da memória do Windows revelados, em inglês) de Mark Russinovich: parte 1 e parte 2.

Os aplicativos com o estilo Metro, no entanto, são diferentes dos aplicativos da área de trabalho, no sentido em que eles são geralmente suspensos sempre que deixam de estar no primeiro plano. Quando eles são suspensos, eles não estão acessando NENHUMA das suas memórias.

Para ilustrar, destaquei alguns aplicativos com o estilo Metro suspensos e com a memória retida em seus conjuntos de trabalho nas capturas de tela abaixo.

Aplicativos suspensos retendo memória

OBSERVAÇÃO: Na compilação do Consumer Preview, o status de suspensão não é mostrado
na exibição dos processos do Gerenciador de Tarefas por padrão. Você tem de escolher para que ele seja mostrado
selecionando uma opção no menu Exibir.

Se não houver pressão da memória em um sistema, será uma boa ideia (pois é mais eficiente) apenas deixar memória nos conjuntos de trabalhos dos aplicativos suspensos. Mas se houver alguma pressão de memória, o fato de que esses aplicativos com o estilo Metro são suspensos apresenta uma oportunidade para se realocar quase toda a memória nesses conjuntos de trabalho de volta para outros aplicativos, sem precisar terminá-los.

Recuperando a memória de aplicativos com o estilo Metro suspensos

No Windows 8 Consumer Preview, podemos gravar com eficiência todo o conjunto de trabalho (particular) de um aplicativo com o estilo Metro suspenso em um disco, para se obter memória adicional quando o sistema detecta pressão.

Este processo é análogo ao processo de hibernação de um aplicativo específico e à continuação quando o usuário volta a usar o aplicativo. Estamos tirando vantagem do mecanismo de suspender/continuar dos aplicativos com o estilo Metro para esvaziar ou repopular um conjunto de trabalho de um aplicativo.

A sequência de eventos é descrita abaixo:

1. O Gerenciador do Tempo de Vida de Processos (PLM) detecta a pressão da memória no sistema e solicita ao Gerenciador de Memória (MM) que esvazie o conjunto de trabalho de um processo específico que armazena um aplicativo com o estilo Metro suspenso.

1. O MM move as páginas de memória de um conjunto de trabalho do aplicativo para a lista de páginas modificadas do sistema operacional (que é uma lista de memória cujos conteúdos devem ser gravados no disco antes de serem reutilizados).

1. As páginas do conjunto de trabalho na listas de páginas modificadas são gravadas de maneira assíncrona, conforme determinado pelas políticas comuns do MM (gravadas convenientemente no plano de fundo, as gravações são acionadas quando estão sob pressão da memória).

1. Mesmo depois que o conjunto de trabalho dos aplicativos suspensos são gravados no disco, as páginas de memória são removidas de um processo são deixadas intactas na lista de espera do sistema operacional. Isto é um cache de páginas úteis da memória que podem ser redefinidas para outros aplicativos se necessário. Se essas páginas são acessadas de novo por seus processos originais, elas rapidamente voltam a ser movidas.

Se um usuário alternar para um aplicativo enquanto suas páginas de conjunto de trabalho ainda estiverem na memória física (na lista de página modificada ou lista de espera), é bem simples: as páginas serão adicionadas de volta ao processo do aplicativo imediatamente. Se elas não estiverem mais disponíveis, o Windows lerá no conjunto de trabalho do aplicativo do disco de uma maneira otimizada.

“Recuperando a memória” durante a ação

Para entender como isso funciona, vamos falar sobre um exemplo com um código de execução real.

O estado inicial é representado pela captura de tela acima. Tive muitos aplicativos com o estilo Metro em um PC com 2 GB de RAM. Os aplicativos com o estilo Metro estavam no plano de fundo e portanto o Windows o suspendeu. Em seguida, comecei a abrir mais aplicativos para direcionar o uso de memória no sistema e acionar a nova funcionalidade.

Na captura de tela abaixo, você perceberá que abri alguns aplicativos para introduzir pressão de memória adicional e induzir o comportamento descrito acima. Como você pode ver, o Windows esvaziou os conjuntos de trabalho dos aplicativos com o estilo Metro suspensos (destacados).

Conjunto de trabalho dos aplicativos com o estilo Metro esvaziado

Vamos comparar os conjuntos de trabalho “antes” e “depois” dos aplicativos com o estilo Metro originais (algumas das estatísticas do “depois” não podem ser vistas porque faltou espaço no Gerenciador de Tarefas para mostrar todos os 27 aplicativos iniciados):

Então, neste exemplo, liberamos mais de 250 MB de RAM física para outros aplicativos usarem sem que seja necessário desligar os aplicativos suspensos.

Capacidade de resposta ao voltar a ler o conjunto de trabalho

Um teste para este novo recurso é o quanto aumenta a capacidade de resposta de um aplicativo suspenso depois que o conteúdo do seu conjunto de trabalho é esvaziado e você decide alternar de volta para o aplicativo.

Enquanto eu executava este teste, usei o aplicativo “Lyrics” como meu indicador de capacidade de resposta. O aplicativo Lyrics pode exibir as letras de uma música assim como reproduzir um vídeo de música. Quando o aplicativo Lyrics vai para o plano de fundo, ele fica suspenso, o que para a reprodução.

Depois de direcionar o uso de memória para o ponto em que os conjuntos de trabalho foram esvaziados, abri aplicativos adicionais e usei o sistema por alguns instantes para ter certeza de que alternar de volta para o aplicativo permitiria a leitura do conjunto de trabalho do disco. Então alternei novamente para o aplicativo Lyrics (abaixo).

O conjunto de trabalho do aplicativo Lyrics é repopulado

O indicador-chave que eu estava procurando era quanto tempo levaria entre o momento em que eu alternei de volta para o aplicativo e o ponto em que pudesse ouvir o som novamente. Em uma máquina básica, com um carregamento alto de memória, é difícil notar a diferença na capacidade de resposta ao alternar de volta para o aplicativo cujo conjunto de trabalho estava sendo lido de um disco se comparado com o momento quando seu conjunto de trabalho ainda estava na memória. No entanto, sua milhagem sofrerá variação: quanto maior o conjunto de trabalho, mais tempo levará para ocorrer a leitura do disco. Também estamos continuamente reduzindo o quanto temos de gravar em um disco para os aplicativos com o estilo Metro, além de otimizar ainda mais este recurso.

Esta funcionalidade é algo que nem todos com o a versão do Consumer Preview podem testar. Basta abrir uma série de aplicativos com o estilo Metro e aplicativos da área de trabalho para gerar uma pressão de memória e, então, alternar de volta para um aplicativo com o estilo Metro que teve o seu conjunto de trabalho esvaziado.

OBSERVAÇÃO: O Windows continuará fechando os aplicativos com o estilo Metro se a memória atingir uma margem crítica. Contudo, este recurso habilitará um sistema para executar mais aplicativos antes de atingir aquele ponto.

Lendo um conjunto de trabalho de maneira otimizada

Para se obter uma capacidade de resposta melhor ao alternar de volta para um aplicativo suspenso cujo conjunto de trabalho esteja no disco, otimizamos, em primeiro lugar, a maneira como gravamos o conjunto de trabalho para que a leitura seja o mais eficiente possível.

Ao gravarmos o conjunto de trabalho de um aplicativo com o estilo Metro, as páginas do conjunto de trabalho são gravadas no disco sequencialmente. Isso nos permite ler os dados que retornam a um processo utilizando uma pequena séries de leituras de disco sequenciais grandes. A captura de tela abaixo é da ferramenta Analisador de Desempenho do Windows (WPA) que vem como parte do Kit de Avaliação e Implantação (ADK), mostrando uma representação visual das leituras de disco durante este processo. Eu destaquei o E/S de “leitura“ do conjunto de trabalho. É possível ver claramente o fluxo sequencial conforme repopulamos um conjunto de trabalho do aplicativo.

E/Ss de leitura sequencial para repopular um conjunto de trabalho do aplicativo (Ferramenta WPA)

Ler novamente dados sequencias de praticamente qualquer dispositivo de armazenamento é muito rápido. A maioria dos disco rotacionais pode alcançar entre 50 e 100 MB por segundo. Se um dispositivo de armazenamento é baseado em flash (como uma SSD), é possível obter até 200 MB por segundo para essas leituras.

Esperamos que muitos aplicativos levem menos do que um segundo da E/S para transportar o conjunto de trabalho de um aplicativo de volta à memória.

Conclusão

Por definição, todos os PCs de todos os fatores forma têm memória física limitada. Os desafios do gerenciamento de memória não mudam quando você adiciona mais memória física, desde que você esteja executando mais programas que exijam mais memória.

Inúmeras classes de softwares modernos continuarão a evoluir para usar cada vez mais memória: edição de fotos de imagens RAW gigantes, base de dados na memória, planilhas muito extensas etc. Sejam essas implementações baseadas em WinRT ou implementações de área de trabalho, o sistema operacional precisa evoluir para gerenciar essas solicitações de memória sempre crescentes. O WinRT é uma oportunidade para os programadores usarem uma API que permite acesso a toda a memória necessária enquanto colocam o usuário em primeiro lugar em termos de capacidade de resposta e realização de tarefas. Espero que você experimente este recurso no Windows 8 Consumer Preview.

-- Bill Karagounis