High Frequency Heap

1

Cada variable estática se almacena en el montón, independientemente de si se trata de declarada dentro de un tipo de referencia o un tipo valor. Solo hay una ranura en total sin importar cuántas instancias se creen . (No es necesario que haya instancias creadas para esa ranura a existe). Tenga en cuenta que este montón es separado de la basura normal montón acumulado: se lo conoce como "alto montón de frecuencia", y hay uno por dominio de aplicación .

Robo de here.

Fuente

2010-12-10 04:26:55

+0

¿quiere decir que el recolector de basura no está trabajando con variables estáticas? Entonces, ¿cómo puede disponer de la memoria? – Vikram

+0

Entonces, ¿qué es la diferencia entre la clase estática y las variables estáticas o el método? – Vikram

+2

El objetivo de las variables estáticas es que existen durante el ciclo de vida del dominio de aplicación, por lo que, por definición, nunca se recolectarán como basura, al menos no hasta que finalice el dominio/proceso de aplicación. En cuanto a las diferentes clases estáticas, métodos estáticos y variables estáticas, son completamente diferentes y la diferencia es C# 101.Las variables estáticas son de "nivel de clase": se crea una instancia de la variable en el dominio de la aplicación, con el alcance correspondiente a la clase en la que se encuentra. Los métodos estáticos son métodos de una clase que no necesitan ser invocados en una instancia; básicamente son funciones globales. –

7

El montón de alta frecuencia se utiliza para almacenar estructuras de datos internas comúnmente utilizadas, como la tabla de tipos de métodos. Esto se puede verificar utilizando WinDbg/SOS como se muestra a continuación.

También se indica en el SSCLI book (p.235).

Aquí es parte de la salida para !eeheap

-------------------------------------- 
Domain 1:   006428c0 
LowFrequencyHeap: 00340000(2000:2000) Size: 0x2000 (8192) bytes. 
HighFrequencyHeap: 00342000(8000:2000) Size: 0x2000 (8192) bytes. 
StubHeap:   Size: 0x0 (0) bytes. 
Virtual Call Stub Heap: 
    IndcellHeap:  Size: 0x0 (0) bytes. 
    LookupHeap:  Size: 0x0 (0) bytes. 
    ResolveHeap:  Size: 0x0 (0) bytes. 
    DispatchHeap: Size: 0x0 (0) bytes. 
    CacheEntryHeap: Size: 0x0 (0) bytes. 
Total size:  Size: 0x4000 (16384) bytes. 
-------------------------------------- 
Jit code heap: 
LoaderCodeHeap: 004e0000(10000:1000) Size: 0x1000 (4096) bytes. 
Total size:  Size: 0x1000 (4096) bytes. 
-------------------------------------- 
Module Thunk heaps: 
Module 5ef21000: Size: 0x0 (0) bytes. 
Module 00342e9c: Size: 0x0 (0) bytes. 
Total size:    Size: 0x0 (0) bytes. 
-------------------------------------- 
Module Lookup Table heaps: 
Module 5ef21000: Size: 0x0 (0) bytes. 
Module 00342e9c: Size: 0x0 (0) bytes. 
Total size:    Size: 0x0 (0) bytes. 
-------------------------------------- 
Total LoaderHeap size: Size: 0x13000 (77824) bytes. 
======================================= 
Number of GC Heaps: 1 
generation 0 starts at 0x02521018 
generation 1 starts at 0x0252100c 
generation 2 starts at 0x02521000 
ephemeral segment allocation context: none 
segment  begin allocated size 
02520000 02521000 0252e010 0xd010(53264) 
Large object heap starts at 0x03521000 
segment  begin allocated size 
03520000 03521000 03523250 0x2250(8784) 
Total Size:    Size: 0xf260 (62048) bytes. 
------------------------------ 
GC Heap Size:   Size: 0xf260 (62048) bytes.

Aviso la ubicación del montón alta frecuencia y los montones de basura recogida. Aquí está la salida para !dumpobject para una instancia estáticamente asignada de Program.

0:000> !dumpheap -type Program 
Address  MT  Size 
0252b630 00343858  12  
total 0 objects 
Statistics: 
     MT Count TotalSize Class Name 
00343858  1   12 TestBench2010.Program 
Total 1 objects 
0:000> !do 0252b630 
Name:  TestBench2010.Program 
MethodTable: 00343858 
EEClass:  0034154c 
Size:  12(0xc) bytes 
File:  C:\workspaces\TestBench2010\TestBench2010\bin\Debug\TestBench2010.exe 
Fields: 
     MT Field Offset     Type VT  Attr Value Name 
00343858 4000001  4 ...Bench2010.Program 0 static 0252b630 p 
0:000> !dumpheap -type Program 
Address  MT  Size 
0252b630 00343858  12  
total 0 objects 
Statistics: 
     MT Count TotalSize Class Name 
00343858  1   12 TestBench2010.Program 
Total 1 objects 
0:000> !do 0252b630 
Name:  TestBench2010.Program 
MethodTable: 00343858 
EEClass:  0034154c 
Size:  12(0xc) bytes 
File:  C:\workspaces\TestBench2010\TestBench2010\bin\Debug\TestBench2010.exe 
Fields: 
    MT Field Offset     Type VT  Attr Value Name 
00343858 4000001  4 ...Bench2010.Program 0 static 0252b630 p

anuncio la dirección de la referencia estática p en el tipo Program. Apunta a una dirección en el montón recogido de basura. Además, observe la dirección de la Tabla de métodos. Apunta a una dirección en el montón de alta frecuencia.

Fuente

2010-12-10 05:14:37

1

Hay una buena visión general de los diversos "montones de cargadores", de los cuales el montón de alta frecuencia es un ejemplo, en este excellent MSDN article on .Net runtime internals.

A partir de ese artículo:

artefactos se accede con frecuencia como MethodTables, MethodDescs, FieldDescs, y mapas de interfaz quedan asignados sobre una HighFrequencyHeap, mientras que las estructuras menos frecuentemente visitada de datos, como EEClass y cargador de clases y sus tablas de búsqueda, obtener asignado en un LowFrequencyHeap. StubHeap aloja stubs que facilitan la seguridad de acceso de código (CAS), llamadas de contenedor COM y P/Invoke.

Fuente

2010-12-10 05:21:31 codekaizen

+0

El enlace está muerto: - \ – Vlad

+0

Ugh, ¿por qué la EM puede tratar las URL de los artículos como deberían tratarse, como recursos permanentes. ¿Alguna vez aprenderán? Corregido gracias a Internet Archive. Por favor considere una donación! www.archive.org – codekaizen

+1

O tal vez [esto] (http://download.microsoft.com/download/3/a/7/3a7fa450-1f33-41f7-9e6d-3aa95b5a6aea/MSDNMagazineMay2005en-us.chm) (advertencia:. chm adentro). – Vlad

-3

El punto del montón de alta frecuencia es que los objetos a los que se accederá con frecuencia se almacenan cerca el uno del otro. Esto minimiza el conjunto de trabajo del proceso.

Fuente

2010-12-10 06:11:59 Gabe

+0

Esto realmente no suena correcto, en términos de CLR, de todos modos. – codekaizen

+0

codekaizen: ¿Qué parte de eso no suena correcto? – Gabe

Respuesta

Cuestiones relacionadas