¿Cómo sabe el sistema operativo cuánta memoria está usando mi aplicación? (¿Y por qué no hace la recolección de basura?)

Question

Cuando mi administrador de tareas (arriba, ps, taskmgr.exe o Finder) dice que un proceso está usando XXX KB de memoria, ¿qué es exactamente lo que cuenta y cómo lo hace? se actualiza?

En términos de asignación de memoria, ¿una aplicación escrita en C++ "aparece" diferente a un sistema operativo desde una aplicación que se ejecuta como una máquina virtual (código administrado como .NET o Java)?

Y, por último, si la memoria es tan transparente, ¿por qué la recolección de basura no es una función o servicio proporcionado por el sistema operativo?

---

Como resultado, lo que estaba muy interesado en hacernos es por qué el sistema operativo no pudo hacer la recolección de basura y el espacio de memoria de desfragmentación - que veo como un paso por encima "simplemente" la asignación de espacio de direcciones de procesos.

¡Estas respuestas ayudan mucho! ¡Gracias!

Answer 1

Este es un gran tema que no puedo responder adecuadamente en una sola respuesta aquí. Recomiendo recoger una copia de Windows Internals, es un recurso invaluable. Eric Lippert tenía una publicación de blog reciente que es una buena descripción de cómo se puede ver la memoria asignada por el sistema operativo.

La memoria que utiliza un proceso es básicamente address space reservada por el sistema operativo que puede estar respaldada por la memoria física, el archivo de página o un archivo. Esto es lo mismo ya sea una aplicación administrada o una aplicación nativa. Cuando el proceso finaliza, el sistema operativo borra la memoria que le había asignado: el espacio de direcciones virtuales simplemente se elimina y el archivo de página o los respaldos de la memoria física son libres para que otros procesos los utilicen. Esto es todo lo que realmente mantiene el sistema operativo: asignaciones del espacio de direcciones a algún recurso físico. Las asignaciones pueden cambiar a medida que los procesos demandan más memoria o están inactivos: el contenido de la memoria física se puede desplazar al disco y viceversa por el sistema operativo para satisfacer la demanda. Lo que un proceso está usando de acuerdo con esas herramientas puede significar una de varias cosas: puede ser espacio total de direcciones asignado, memoria total asignada (archivo de página + memoria física) o memoria que usa un proceso residente en memoria. Task Manager tiene una columna separada para cada una de estas posibilidades.

El sistema operativo no puede hacer la recolección de elementos no utilizados, ya que no tiene ninguna idea de lo que contiene realmente la memoria: solo ve las páginas de memoria asignadas, no ve objetos a los que se puede hacer referencia o no.

Mientras que los controladores OS se asignan al nivel de dirección virtual, en el proceso hay otros administradores de memoria que toman estos trozos grandes del tamaño de una página y los dividen en algo útil para que lo use la aplicación. Windows devolverá la memoria asignada en límites de 64k, pero luego el administrador del montón la divide en trozos más pequeños para que los use cada asignación individual hecha por el programa a través del new. En aplicaciones .Net, el CLR transferirá nuevos objetos fuera del montón recogido de basura y cuando ese montón alcance sus límites, realizará la recolección de basura.

Answer 2

No puedo responder a su pregunta sobre las diferencias en la forma en que aparece la memoria en C++ frente a las máquinas virtuales, etc., pero puedo decir que las aplicaciones suelen tener un determinado rango de memoria para usar al inicializar. Luego, si la aplicación alguna vez requiere más, la solicitará desde el sistema operativo, y el sistema operativo (generalmente) la otorgará. Hay muchas implementaciones de esto: en algunos sistemas operativos, la memoria de otras aplicaciones se aleja para que el tuyo tenga un bloque contiguo más grande y, en otros, tu aplicación obtiene varios trozos de memoria.Incluso puede haber algún manejo de memoria virtual involucrado. Todo depende de una implementación abstracta. En cualquier caso, la memoria aún se trata como contigua desde dentro de su programa; el sistema operativo manejará eso al menos.

Con respecto a la recolección de basura, el sistema operativo conoce los límites de su memoria, pero no lo que está adentro. Además, incluso si mirara la memoria utilizada por su aplicación, no tendría idea de qué bloques son utilizados por variables fuera del alcance y de modo que el GC lo esté buscando.

Answer 3

La principal diferencia es la gestión de aplicaciones. Microsoft lo distingue como Administrado y No administrado. Cuando los objetos se asignan en la memoria, se almacenan en una dirección específica. Esto es cierto para aplicaciones administradas y no administradas. En el mundo administrado, la "dirección" está envuelta en un identificador de objeto o "referencia".

Cuando la memoria es basura recogida por una VM, puede suspender la aplicación de forma segura, mover objetos en la memoria y actualizar todas las "referencias" para señalar sus nuevas ubicaciones en la memoria.

En una aplicación de estilo Win32, los punteros son punteros. El sistema operativo no tiene forma de saber si se trata de un objeto, un bloque de datos arbitrario, un valor simple de 32 bits, etc. Por lo tanto, no puede hacer ninguna inferencia sobre punteros entre objetos, por lo que no puede moverlos. alrededor de la memoria o actualizar punteros entre objetos.

Como se manejan las referencias de ruta, el sistema operativo no puede asumir el control del proceso de GC y, en cambio, depende de la máquina virtual gestionar la memoria utilizada por la aplicación. Por esa razón, las aplicaciones de VM aparecen exactamente iguales para el sistema operativo. Simplemente solicitan bloques de memoria para su uso y el sistema operativo se los proporciona. Cuando la máquina virtual realiza GC y compacta su memoria, puede volver a liberar la memoria en el sistema operativo para que la use otra aplicación.