Ha pasado mucho tiempo desde que aprendí esto, pero aquí va.
Cuando un sistema operativo inicia un proceso, le asigna páginas de la tabla de memoria virtual. El sistema operativo es responsable de mantener un mapa desde la tabla de memoria virtual a la memoria real o al espacio de intercambio en el disco. Cuando se mata un proceso, el sistema operativo no deja de darle ciclos de CPU. Realiza algunos elementos de limpieza, uno de los cuales es marcar todas sus páginas de memoria como gratuitas. Esto les permite ser reutilizados por otras aplicaciones. El sistema operativo probablemente también limpiará todos los identificadores de recursos que tenía el proceso, cerrando automáticamente archivos, conexiones de red, canalizaciones de proceso a proceso, etc. Este proceso está completamente bajo el control del sistema operativo, y estos pasos se tomarán sin importar cómo murió el proceso.
Tenga en cuenta que todo esto se aplica a los procesos del sistema operativo. Si tiene algún tipo de máquina virtual y ejecuta múltiples procesos virtuales a la vez, la VM es responsable de decidir cómo asignarlos y desasignarlos. Desde el sistema operativo, sin embargo, todavía parece un proceso. Entonces, en este caso, si tiene una VM que ejecuta múltiples procesos y elimina uno de ellos dentro de la VM, entonces probablemente no recuperará la memoria de inmediato en el sistema operativo host. Pero lo recuperarás en la VM. Sin embargo, si mata la VM dentro del sistema operativo, el sistema operativo matará la VM (que indirectamente mata los procesos de la VM) y recuperará toda la memoria (que no necesitará pasar por un recolector de basura, libre () , eliminar o cualquier otra cosa).
Altamente especulativo:
Si .NET se ejecuta como una máquina virtual con más de una aplicación .NET en la misma VM, .NET podría conservar la memoria que aún no es GCd, hasta que ejecute el GC, y Windows pensaría que .NET es usando más de lo que realmente es. (Y si MS era realmente astuto, Windows podría decirle a .NET a GC en situaciones de poca memoria, pero casi no tiene sentido porque para eso es el espacio de intercambio de disco).
Si .NET funcionara de esa manera, entonces el sistema operativo aún lo consideraría como un proceso para fines del sistema operativo, que asume la responsabilidad de decidir qué conservar y qué desechar, y normalmente no es problema de Windows decirle a un proceso que necesita para comenzar a desasignar la memoria. En ese momento es concebible que MS construya una API especial solo para .NET para que los procesos .NET se vean como procesos de Windows, excepto que no lo son, por lo que la gente podría pensar que la memoria del proceso no se está desasignando. Es realmente; es solo que estás viendo el proceso incorrecto.
No sé lo suficiente sobre .NET como para decir que realmente funciona de esa manera; Java VM ciertamente no.
Fin de la especulación.
EDITAR: en lo que concierne a matar un proceso que es malo para la gestión de la memoria, eso requiere que múltiples procesos se asignen fuera del mismo grupo (es decir, son más como hilos que procesos reales) y que la memoria no se libere después de que el proceso esté delicado. Eso casi requeriría un sistema multitarea cooperativo, porque la memoria virtual y la multitarea preventiva, por lo que sé, generalmente se implementan juntas (la VM hace posible aislar los procesos entre sí y evitar que pisoteen la memoria del otro). Tener memoria virtual hace que la limpieza sea trivial después de un proceso en el nivel del sistema operativo; simplemente mueve todas las páginas del grupo de procesos al grupo libre.