memoria de imagen disminución

Question

estoy corriendo este código:

#include <iostream> 
#include <cstddef> 


int main(int argc, char *argv[]){ 
    int a1=0, a2=0; 
    int a3,a4; 

    int b1=++a1; 
    int b2=a2++; 

    int*p1=&a1; 
    int*p2=&++a1; 

    size_t st; 
    ptrdiff_t pt; 

    int i=0; 
    while(true){ 
     printf("i: %d",i++); 
    } 
    printf("\n\ni now is: %d\n",i); 
    return 0; 
} 

¿Por qué puedo observar esta disminución en la memoria de imagen (fiolet): leyenda:

que hizo posible este proyecto general de Win32, no CLR Cambié el código, así que veré cuando int se ha vuelto finalmente negativo. Ahora el tiempo() es:

int i=0; 
    while(0<++i){ 
     printf("i: %d",i++); 
    } 
    printf("\n\ni now is: %d\n",i); 

Es extraño: por favor ver qué sucedió después de sólo 30.000 iteraciones. ¿Por qué vemos estas fluctuaciones en la memoria de imagen? Ahora puedo ver que probablemente esto esté relacionado con VMMap, porque solo ocurre si elijo "iniciar & rastrear un nuevo proceso", pero no cuando "ver un proceso en ejecución" y apuntar a ejecutar ejecutado desde VS2010. Aquí está la pantalla de proceso "lanzado & trazado":

me observó también enorme de paginación de la memoria, que comenzó más o menos con esta disminución de la imagen (esto paginación casi acelerada y el límite de memoria RAM disparado rápidamente, de que he puesto a 2 GB): y aquí es un proceso que se ejecuta solamente "visto" (recorrida desde VS2010):

así que tal vez algún tema sujeto a la gestión de memoria de las aplicaciones .NET tiene lugar aquí? Todavía estoy esperando que mi int cruce el límite de dos complementos.

bueno ... Tengo que volver a editar: resulta que, como se pensaba anteriormente, el efecto de disminución de la imagen de la memoria está presente cuando el proceso solo se ve (no se inicia) también. A continuación se adjunta la imagen del mismo proceso 10 minutos más tarde (a la espera de convertir int en negativo):

y aquí está:

por lo que el peor positivo 2-complemento en mi la máquina es de 2 147 483 647 y negativa más pequeña es de -2 147 483 648, lo que es fácil comprobar de esta manera:

#include <limits> 
const int min_int = std::numeric_limits<int>::min(); 
const int max_int = std::numeric_limits<int>::max(); 

que me dio el mismo resultado: 14 -2 7 483 648 y 2 147 483 647

de nuevo al principio cuando comento todo, pero el bucle while() - sucede lo mismo: la imagen está disminuyendo después del proceso estaba corriendo alrededor de 10 minutos, por lo que no es lo inútil código que causa esto. ¿pero que?

Answer 1

El conjunto de trabajo está en gran medida bajo el control del sistema operativo. Lo que su código hace es solo un factor que considera al decidir si crecer o recortar su conjunto de trabajo. Otros factores incluyen si su aplicación está en primer plano, cuán activa es, cuán codicioso es el algoritmo de montón, cuánta memoria existe debido a las demandas de otros procesos, etc. Esto es por diseño.

Las caídas probablemente estén relacionadas con la elección de Windows para recortar su conjunto de trabajo. Dado que la mayor parte del código que se cargó originalmente probablemente fue solo para la inicialización y no está involucrado en el ciclo, para el sistema operativo fue sencillo recuperar las páginas de imágenes en función de un algoritmo LRU.

Observe que el conjunto de trabajo asignado al tamaño de la imagen no es la única parte que se recortó.