martes, 14 de febrero de 2012

TOP 5: FUNDAMENTOS DE GESTIÓN DE MEMORIA EN .NET


I ¿Qué sucede con los objetos pequeños?

Objetos pequeños en .NET. Se aplican sobre las pilas de objetos pequeños (SOH). Hay tres de ellas: la generación 0, Generación 1 yGeneración 2. Los objetos se mueven a estas generaciones en función de su edad.

Los nuevos objetos se colocan en GEN 0. Cuando Gen 0 se llena, el Colector .NET basura (GC) se ejecuta, la eliminación deobjetos que ya no son necesarios y mover todo lo demás hasta Gen 1. Si Gen 1 se llena de la GC se ejecuta de nuevo, pero también se mueve objetos en Gen 1 hasta Gen 2.

Un análisis completo con GC ocurre cuando Gen 2 se llena. Esto borra los objetos innecesarios Gen 2, Gen 1 se mueve objetos a Gen 2, luego se mueve Gen 0 objetos a Gen 1, y finalmente se borra todo lo que no se hace referencia. Después de cada ejecución de GC, los montones de afectados se compactan, para mantener la memoria, que todavía está en uso en conjunto.

Este enfoque generacional mantiene las cosas funcionando de manera eficiente - el proceso que consume tiempo de compactación se produce sólo cuando sea absolutamente necesario.

Recuerde: si usted ve una alta proporción de la memoria en Gen 2, es un indicador de la memoria se lleva a cabo a durante mucho tiempo, y puede ser una señal de que tienes un problema de memoria. Aquí es donde una herramienta de perfiles de memoria, tales como perfiles de memoria ANTS, puede venir muy bien.

II ¿Qué sucede con los objetos más grandes?

Objetos de más de 85 KB se asignan en el montón de objetos grandes (LOH). No se compactan, debido a la sobrecarga de copiar grandes trozos de memoria. Cuando un GC completa se lleva a cabo, los rangos de direcciones de los objetos LOH que no estén en uso se registran en una tabla de asignación de espacio libre en su lugar.

Cuando un nuevo objeto se le asigna, la tabla de espacio libre se comprueba para un rango de direcciones con capacidad suficiente para el objeto. Si existe, el objeto se asigna allí, si no, es asignado en el espacio libre de al lado.

Dado que los objetos es poco probable que el tamaño exacto de un rango de direcciones vacía, pequeños trozos de la memoria casi siempre se queda entre los objetos, lo que resulta en la fragmentación. Si estos trozos son menos de 85 KB, no hay posibilidad de reutilización en absoluto. En consecuencia, a medida que aumenta la demanda de asignación, nuevos segmentos están reservados a pesar de que el espacio fragmentado todavía está disponible.

Además, cuando un objeto grande debe ser asignada, .NET tiende a añadir el objeto al final de todos modos, en lugar de ejecutar una costosa Gen 2 GC. Esto es bueno para el rendimiento, pero una causa importante de la fragmentación de memoria.

III. El recolector de basura se puede ejecutar en diferentes modos para optimizar el rendimiento

.NET resuelve el trade-off entre el desempeño y la eficiencia de almacenamiento dinámico, proporcionando múltiples modos para el GC.

El modo de estación de trabajo da respuesta máxima para el usuario y reduce las pausas debido a GC. Puede funcionar como "concurrente" o "no concurrente", refiriéndose a las conversaciones de la GC se ejecuta en. El valor predeterminado es concurrente, que utiliza un subproceso independiente para la GC para que la aplicación puede continuar la ejecución, mientras que GC se ejecuta.

El modo de servidor ofrece el máximo rendimiento, escalabilidad y rendimiento para entornos de servidores. Tamaño del segmento y los umbrales de generación son mucho mayores en el modo de servidor de que el modo de estación de trabajo, lo que refleja las mayores exigencias impuestas a los servidores.

El modo de servidor se ejecuta la recolección de basura en forma paralela en varios subprocesos, la asignación de un SOH separado y LOH para cada procesador lógico para evitar que los hilos de interferir unos con otros.

El framework de. NET proporciona un mecanismo de referencias cruzadas para que los objetos todavía pueden hacer referencia a otra a través de los montones. Sin embargo, como respuesta de las aplicaciones no es un objetivo directo de modo de servidor, todos los hilos de la aplicación se suspende durante la duración de la GC.

IV. Las referencias débiles ofrecen un compromiso entre el rendimiento y la eficiencia de la memoria

Las referencias débiles a objetos es una fuente alternativa de las raíces de GC, lo que le permite mantener objetos, mientras que lo que les permite ser recogida si el GC lo necesita. Son un compromiso entre el rendimiento del código y la eficiencia de la memoria, la creación de un objeto tiene tiempo de CPU, pero mantenerlo cargado toma la memoria.

Las referencias débiles son particularmente adecuadas para estructuras de datos de gran tamaño. Por ejemplo, imagine que tiene una aplicación que permite a los usuarios navegar a través de estructuras de datos de gran tamaño, algunas de las cuales podrían volver. Usted puede convertir cualquier  referencia fuertes a las estructuras que han navegado en referencias débiles. Si los usuarios vuelven a estas estructuras, que están disponibles, pero si no la GC puede reclamar la memoria si es necesario.

V. El fijado de objetos puede crear referencias para pasar entre el código administrado y no administrado

. NET utiliza una estructura llamada GCHandle para realizar un seguimiento de los objetos del montón. GCHandle puede ser usado para pasar referencias de objetos entre dominios administrados y no administrados, y .NET mantiene una tabla de GCHandles para lograrlo. Hay cuatro tipos de GCHandle, entre ellos articulados, que se utiliza para fijar un objeto en una dirección específica en la memoria.

El problema principal con el fijado de objeto es que puede provocar la fragmentación SOH. Si un objeto se fija durante un GC entonces, por definición, no puede ser reubicado. Dependiendo de cómo se use el fijado, se puede reducir la eficiencia de la compactación, dejando huecos en la pila. La mejor política para evitar esto es para fijarlo por un tiempo muy corto y luego soltarlo.

Los Top 5 fundamentos de la gestión de memoria .NET de Ricky  han sido cosechados en un eBook de Chris Farrell y Nick Harrison, bajo la capa de gestión de memoria .NET.

No hay comentarios:

Publicar un comentario