O Project Snowflake é uma tentativa de introduzir o gerenciamento manual de memória no .NET, uma melhoria considerada útil para certos tipos de aplicações. Linguagens de programação modernas, tal como C#/.NET, usam a coleta de lixo (garbage collection) para aliviar os programadores da tarefa de gerenciar objetos alocados na memória, com reconhecido benefício sob os aspectos da produtividade no desenvolvimento, estabilidade do programa, proteção da memória e segurança. Entretanto, essa coleta de lixo implica em um custo adicional no desempenho, que, embora não seja percebido na maioria dos casos, pode ser problemático em alguns. Os pesquisadores do projeto Snowflake citam "data analytics" e "stream processing" rodando em sistemas com centenas de GB (giga bytes) de memória "heap" (memória de alocação dinâmica-em tempo de execução do programa/runtime) como alguns tipos de aplicações que podem se beneficiar com o gerenciamento manual de memória.
O Snowflake propõe a introdução do gerenciamento manual de memória em paralelo ao gerenciamento através da coleta automática, para que desenvolvedores possam usar os mecanismos automáticos de coleta na maioria dos casos, mas também serem capazes de usar o mecanismo manual quando as circunstâncias assim o exigirem. As mudanças introduzidas no runtime não afetarão as aplicações existentes e melhorarão o desempenho das aplicações multitarefa. O Snowflake habilita a "alocação e desalocação de objetos individuais em localizações arbitrárias no programa, e garante que os objetos gerenciados manualmente têm proteção tanto de tipo quanto temporal (type-safety, temporal-safety), mesmo quando há acessos concorrentes."
Esse projeto introduz dois novos conceitos principais: "Owner" (dono) do objeto e o escudo, ou blindagem, do objeto ("Shield"), implementados ao nível dos CoreCLR e CoreFX ("Common Language Runtime e bibliotecas fundamentais da .NET Core). O "Owner" é uma localização no "stack" (memória de pilha-estática, alocada em tempo de compilação) ou no "heap" que armazena uma referência única de um objeto alocado no "heap" manual, ou seja, na memória de alocação dinâmica (de objetos em tempo de execução) que é gerenciada manualmente pelo Snowflake. Um "Owner" é obtido de um "Shield", que é introduzido para evitar a desalocação de objetos gerenciados manualmente quando acessado por múltiplas linhas de execução (threads). O "Shield" garante que o objeto é removido da memória (heap) apenas quando a última linha de execução que o estava estava usando, o liberou (desalocou). O artigo sobre o trabalho de pesquisa explica isso em mais detalhe:
Nossa solução… é inspirada pela abordagem "hazard-pointers", que é uma técnica originada na literatura sobre estrutura de dados "lock-free". Nós introduzimos um mecanismo para publicar no thread-local state (TLS) - memória independente e reservada para a linha de execução, a intenção de uma linha de execução para acessar um objeto manual através de um desses endereços "Owner". Esse registro pode ser pensado como a criação de um escudo que protege o objeto da desalocação e dá permissão para a linha de execução que emitiu o registro acessar diretamente o objeto manual, como por exemplo, fazer chamadas a seus métodos ou alterar seus campos. Nesse mesmo tempo, nenhuma linha de execução (ela mesma, ou outra) é permitida desalocar o objeto e recuperar sua memória. Uma vez que o código cliente não necessite mais acessar esse objeto, ela (a linha de execução-thread) pode dispensar o escudo, que seja, remover a referência para esse objeto do seu TLS. Não é seguro acessar diretamente o objeto que foi obtido através de um escudo, depois que esse escudo foi removido, porque, seguindo a remoção, é permitido o prosseguimento da desalocação real.
O artigo inclui resultados para uma série de testes medindo os benefícios de desempenho em usar Snowflake e não GC (coleta de lixo automática-garbage collection) em certos cenários. Eles obtiveram "economias de até 3 vezes em "peak working sets", que é um conceito da Microsoft de uso de memória por processos rodando no sistema operacional, e de duas vezes em tempo de execução", que representam boas economias. Isso é possível porque para conjuntos muito grandes de objetos o método de GC gasta um tempo considerável para percorrer o grafo de objetos para liberar a memória.
A Microsoft não apresentou planos de incluir ou não a tecnologia Snowflake na .NET, mas podemos esperar que futuras versões da .NET incorporem alguma coisa desse tipo, considerando seus aspectos não intrusivos e seguros.