È da tanto che non imparo queste cose, ma qui va.
Quando un sistema operativo avvia un processo, gli assegna le pagine dalla tabella della memoria virtuale. Il sistema operativo è responsabile del mantenimento di una mappa dalla tabella della memoria virtuale alla memoria reale o allo spazio di scambio sul disco. Quando un processo viene interrotto, il sistema operativo non smette di fornire cicli CPU. Fa alcuni elementi di pulizia, uno dei quali è quello di contrassegnare tutte le sue pagine di memoria come libere. Ciò consente loro di essere riutilizzati da altre applicazioni. Il sistema operativo probabilmente pulirà anche qualsiasi handle di risorse presente nel processo, chiudendo automaticamente file, connessioni di rete, pipe da processo a processo e così via. Questo processo è interamente sotto il controllo del sistema operativo e questi passaggi verranno eseguiti indipendentemente dalla morte del processo.
Tenere presente che tutto ciò si applica ai processi del sistema operativo. Se si dispone di un qualche modo di macchina virtuale e si eseguono più processi virtuali contemporaneamente, la VM è responsabile della decisione su come allocare e deallocare a essi. Dal sistema operativo, tuttavia, sembra ancora un processo. Quindi, in questo caso, se si dispone di una macchina virtuale che esegue più processi e si uccide uno di essi all'interno della macchina virtuale, probabilmente non si recupererà immediatamente la memoria nel sistema operativo host. Ma lo riavrai nella VM. Se uccidi la VM all'interno del sistema operativo, tuttavia, il sistema operativo ucciderà la VM (che uccide indirettamente i processi della VM) e recupererà tutta la memoria (che non dovrà passare attraverso un Garbage Collector, free () , elimina o qualsiasi altra cosa).
Altamente speculativo:
Se .NET viene eseguito come una macchina virtuale con più di un'app .NET sulla stessa macchina virtuale, .NET potrebbe conservare la memoria che non è ancora GCd, fino a quando non esegue GC e Windows penserebbe che .NET sia usando più di quello che è realmente. (E se MS fosse davvero fluido, Windows avrebbe potuto dire a .NET a GC in situazioni di memoria ristretta, ma non ha quasi senso perché questo è lo spazio per lo scambio del disco.)
Se .NET funzionasse in quel modo, il sistema operativo lo considererebbe comunque un processo ai fini del sistema operativo, il che si assume la responsabilità di decidere cosa conservare e cosa buttare via, e normalmente non è un problema di Windows dire a un processo di cui ha bisogno per iniziare la deallocazione della memoria. A quel punto è ipotizzabile che MS costruisca un'API speciale solo per .NET in modo che i processi .NET sembrino processi Windows, tranne per il fatto che non lo sono, motivo per cui le persone potrebbero pensare che la memoria del processo non sia stata deallocata. È davvero; è solo che stai guardando il processo sbagliato.
Non so abbastanza su .NET per dire che funziona davvero in quel modo; la VM Java certamente no.
Fine della speculazione.
EDIT: per quanto riguarda l'uccisione di un processo che è dannoso per la gestione della memoria, che richiede più processi per allocare dallo stesso pool (cioè sono più simili a thread che processi reali) e per non liberare la memoria dopo che il processo è ucciso. Ciò richiederebbe quasi un sistema multitasking cooperativo, poiché la memoria virtuale e il multitasking preventivo sono stati, a mia conoscenza, di solito implementati insieme (la VM ha reso possibile isolare i processi gli uni dagli altri e impedire loro di calpestare la memoria dell'altro). Avere memoria virtuale rende banale la pulizia dopo un processo a livello di sistema operativo; basta spostare tutte le pagine dal pool del processo al pool gratuito.