¿Matar un proceso todavía se considera malo para la administración de la memoria?

Así que estoy teniendo una pequeña discusión con mi jefe sobre la gestión de la memoria.

Me han dicho que matar un proceso no le permite desasignar la memoria. ¿Sigue siendo así, o fue hace años?

Estamos hablando de Windows y OS X aquí.

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.

No hay problema en mi experiencia, mata.

Como ejemplo, si tiene 4 GB de RAM, de los cuales 3 GB están en uso por un juego y finaliza el proceso del juego, puede reiniciar el juego sin problemas y tendrá 3 GB de RAM en el proceso nuevamente.

Los sistemas operativos enumerados en las etiquetas de preguntas (Windows y OS X) implementan memoria virtual , donde cada proceso recibe su propio espacio de direcciones, que luego el SO asigna a la memoria física. Estas tablas de mapeo se usan para limpiar las asignaciones de memoria cuando se termina un proceso, por lo que la memoria se libera por completo. Las páginas físicas pueden compartirse entre múltiples procesos, en cuyo caso se liberan cuando no hay más usuarios.

Por lo general, otros recursos, como los identificadores de archivos, se otorgan a los procesos en forma de capacidades , donde el proceso recibe un identificador del recurso y lo manipula a través de funciones de acceso bien definidas. El sistema operativo mantiene una asignación de tabla del valor del identificador al objeto en el núcleo que proporciona la función; de nuevo, esta tabla se puede usar para la limpieza cuando se termina un proceso.

Hay recursos especiales que sobreviven al proceso que los creó, por ejemplo, es posible crear asignaciones de memoria compartida con nombre persistente que se pueden usar en la comunicación entre procesos. Raramente se usan, precisamente porque el sistema operativo no puede determinar si todavía son necesarios.

En otros sistemas operativos, a veces no hay una separación clara del proceso; Esto coloca la carga de la limpieza en aplicaciones individuales.

El cierre forzado de un proceso terminará el proceso sin darle ninguna posibilidad de limpieza; Si el sistema operativo tiene una lista completa de todos los recursos, esto no tiene efectos adversos.

Eso fue en el día anterior a la implementación de la administración de memoria. Hoy en día, la única memoria que puede perderse es la memoria utilizada por los controladores y los módulos del kernel que permanecen inexpertos o zombis, pero eso es realmente maní.