Matar um processo ainda é considerado ruim para o gerenciamento de memória?

Então, eu estou tendo uma pequena discussão com meu chefe sobre gerenciamento de memória.

Foi-me dito que matar um processo não permite desalocar memória. Ainda é esse o caso, ou foi anos atrás?

Estamos falando do Windows e do OS X aqui.

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.

Não tem problema na minha experiência, mate.

Por exemplo, se você tiver 4 GB de RAM, dos quais 3 GB estão em uso por um jogo e interromper o processo, poderá reiniciar o jogo sem problemas e ele terá 3 GB de RAM no processo novamente.

Os sistemas operacionais listados nas tags de pergunta (Windows e OS X) implementam memória virtual , onde cada processo recebe seu próprio espaço de endereço, que é mapeado para a memória física pelo sistema operacional. Essas tabelas de mapeamento são usadas na limpeza de alocações de memória quando um processo é finalizado, para que a memória seja completamente liberada. As páginas físicas podem ser compartilhadas entre vários processos; nesse caso, elas são liberadas quando não há mais usuários.

Normalmente, outros recursos, como identificadores de arquivo, são fornecidos a processos na forma de recursos , nos quais o processo recebe um identificador e o manipula por meio de funções de acesso bem definidas. O sistema operacional mantém um mapeamento de tabela do valor do identificador para o objeto no kernel que fornece a função; novamente, esta tabela pode ser usada para limpeza quando um processo é finalizado.

Existem recursos especiais que sobrevivem ao processo que os criou, por exemplo, é possível criar alocações de memória compartilhada nomeadas persistentes que podem ser usadas na comunicação entre processos. Eles raramente são usados, precisamente porque o sistema operacional não pode determinar se eles ainda são necessários.

Em outros sistemas operacionais, às vezes não há separação clara do processo; isso coloca o ônus da limpeza em aplicativos individuais.

O fechamento forçado de um processo encerrará o processo sem dar chance de limpeza; se o sistema operacional tiver uma lista completa de todos os recursos, isso não terá efeitos adversos.

Isso foi no dia anterior ao gerenciamento de memória ser amplamente implementado. Atualmente, a única memória que você pode perder é a memória usada por drivers e módulos do kernel que permanecem sem qualificação ou zumbis, mas isso é realmente amendoim.