.NET CF e gestão de memória virtual – Será esta uma descoberta revolucionária?

Um título destes seria digno de abertura de um qualquer telejornal nacional!

Recebi hoje pelo Newsgator/FeedDemon um artigo que a confirmar-se pode revolucionar tudo quanto tem sido escrito sobre as limitações de memória na execução de aplicações .NET Compact Framework. Eu assumo, não sou um entendido em arquitectura de computadores, mas em traços gerais, o panorama é mais ou menos este:  o Windows CE desde a versão 1.0 até à sua versão 5.0 permitem até 32 processos simultâneos, alocando até 32mb de memória a cada um, o que significa que cada aplicação vive dentro de um cubículo de até 32mb, independentemente da quantidade de memória que o equipamento tenha. Na prática, esses 32mb acabam por nunca estarem disponíveis… muitos equipamentos não dispoem sequer de 32mb livres de RAM e quando dispoem, a forma como são carregadas as DLL em código nativo leva a que o seu espaço seja reservado transversalmente entre todos os processos já criados, e mesmo os criados a posteriori.

No caso das aplicações .NET CF, a limitação da memória virtual mantém-se, embora existam algumas diferenças para as aplicações em código nativo, nomeadamente as DLL não ocuparem ‘transversalmente’ o tal espaço em todos os processos referido acima. Posso dizer-vos que já dispendi mais do que um dia a ler blogs, artigos no CodeProject e documentação na MSDN sobre este assunto da gestão em memória em Windows CE e pela .NET CF e sobre o Garbage Collector [1].

Muitas vezes só nos lembramos destas questões da memória quando nos rebenta uma OutOfMemory (OOM) exception – oh p’ra mim a assobiar para o ar – e se algumas situações são facilmente contornáveis, outras podem levar a uma restruturação de trabalho já feito. Uma situação em particular que pode conduzir a estas OOM e potencialmente cada vez mais fre quente, é a realização de operações gráficas com manipulação em memória de bitmaps do tamanho do ecrã em equipamentos de alta resolução, como os VGA e o WVGA, onde um bitmap que num equipamento normal conta com as dimensões de 240×320 vê o seu tamanho multiplicado por 4 no caso do VGA e por 5 no caso do WVGA. A conta é fácil de fazer, se a cada pixel corresponderem dois bytes, de 153kb passamos a 614kb e 768kb respectivamente [2].

Até chegar um sistema operativo Windows Mobile baseado em Windows CE 6.0 ou posterior, o que se espera que aconteça com a próxima grande versão do Windows Mobile, onde cada processo poderá contar com até 2GB para um máximo de 32000 processos a correr em simultâneo(!), pouco parecia haver a fazer para além de optimizar as aplicações actuais e usar as ferramentas das Powertoys (.NET CF CLR Profiler e .NET CF Remote Performance Monitor) para estudar o impacto das modificações efectuadas.

O tal artigo que mencionei no início do tópico é este…

http://blogs.msdn.com/robtiffany/archive/2009/04/09/memmaker-for-the-net-compact-framework.aspx

…e segundo o Rob Tifany, no caso das aplicações .NET CF, se criarmos um exe ‘vazio’ e colocarmos todo o resto do código numa DLL referenciada conseguimos ultrapassar a tal limitação dos 32mb por processo para a nossa aplicação! O artigo é um pouco extenso e técnico, mas é seguramente um must-read por parte de quem desenvolve para .NET CF! A única limitação que a técnica sugerida não contornará será mesmo a limitação crónica de alguns equipamentos com 64mb e menos de RAM, que mesmo após um soft-reset apresentam uma quantidade de RAM disponível abaixo dos 32MB.

Oportunamente testarei esta abordagem numa aplicação onde sei como provocar estes OOM :D

———————

[1] Para os interessados, a partir da seguinte série de artigos do Raffael poderão seguir outros links muito interessantes sobre esta temática:

http://blogs.msdn.com/raffael/archive/tags/Memory/default.aspx

[2 - Correcção]

O João Paulo Figueira alertou-me que cada pixel no ecrã representam dois bytes, e no caso de imagens do tipo PNG e alpha blending, cada pixel chega aos 4 bytes por pixel, ou seja, num equipamento como o HTC Touch HD, até 1,5mb!!!

[3 – Actualização em 2009/04/11 – 8:50]

VirtualMemory[1] A pedido de algumas famílias, a ferramenta que o Rob usa para visualizar a memória virtual ocupada por processo pode ser obtida a partir do seguinte artigo no CodeProject:

 http://www.codeproject.com/KB/mobile/VirtualMemory.aspx

É mais um artigo de leitura recomendada!

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>