Faz muito tempo desde que aprendi essas coisas, mas aqui vai.
Quando um sistema operacional inicia um processo, ele atribui as páginas da tabela de memória virtual. O sistema operacional é responsável por manter um mapa da tabela de memória virtual para a memória real ou para o espaço de troca no disco. Quando um processo é interrompido, o sistema operacional não para de dar ciclos de CPU. Faz alguns itens de limpeza, um dos quais é para marcar todas as suas páginas de memória como livres. Isso permite que eles sejam reutilizados por outros aplicativos. O sistema operacional provavelmente também limpará todos os identificadores de recursos que o processo tinha, fechando automaticamente arquivos, conexões de rede, canais processo a processo e assim por diante. Esse processo está totalmente sob o controle do sistema operacional e essas etapas serão executadas, não importa como o processo tenha morrido.
Tenha em mente que tudo isso se aplica aos processos do sistema operacional. Se você tem algum tipo de máquina virtual e está executando vários processos virtuais ao mesmo tempo, a VM é responsável por decidir como alocar e desalocar para eles. No sistema operacional, no entanto, ainda parece um processo. Portanto, neste caso, se você possui uma VM que executa vários processos e mata um deles na VM, provavelmente não recuperará imediatamente a memória no sistema operacional host. Mas você o recuperará na VM. Se você matar a VM no sistema operacional, no entanto, o sistema operacional matará a VM (que indiretamente mata os processos da VM) e recuperará toda a memória (que não precisará passar por um coletor de lixo, livre () , excluir ou qualquer outra coisa).
Altamente especulativo:
Se o .NET for executado como uma máquina virtual com mais de um aplicativo .NET na mesma VM, o .NET poderá manter a memória que ainda não é GCd, até que execute o GC, e o Windows pensaria que o .NET é usando mais do que realmente é. (E se a MS fosse realmente esperta, o Windows poderia informar ao .NET para GC em situações de pouca memória, mas quase não faz sentido, porque é para isso que serve o espaço de troca de disco.)
Se o .NET funcionasse dessa maneira, o sistema operacional ainda pensaria nele como um processo para fins de SO, que assume a responsabilidade de decidir o que manter e o que jogar fora, e normalmente não é problema do Windows dizer ao processo que ele precisa para começar a desalocar a memória. Nesse ponto, é possível que a MS construa uma API especial apenas para .NET, para que os processos .NET se pareçam com os processos do Windows, exceto que não, e é por isso que as pessoas podem pensar que a memória do processo não estava sendo desalocada. É realmente; é só que você está olhando para o processo errado.
Não sei o suficiente sobre o .NET para dizer que ele realmente funciona dessa maneira; a Java VM certamente não.
Fim da especulação.
EDIT: No que diz respeito a matar um processo que é ruim para o gerenciamento de memória, isso exige que vários processos sejam alocados fora do mesmo pool (ou seja, são mais parecidos com threads do que processos reais) e que a memória não seja liberada após o processo ser concluído. morto. Isso exigiria quase um sistema cooperativo de multitarefa, porque a memória virtual e a multitarefa preventiva eram, ao meu conhecimento, geralmente implementadas em conjunto (a VM possibilitando isolar processos um do outro e impedir que eles pisassem na memória um do outro). Ter memória virtual facilita a limpeza após um processo no nível do SO; basta mover todas as páginas do pool do processo para o pool gratuito.