Question

I am running this code:

#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;
}

why do I observe such decrease in image memory (fiolet):

legend:

I made this general Win32 project, not CLR.
I changed the code, so I will see when int has become finally negative. Now the while() is:

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

It is strange: please see what happend after just 30000 iterations. Why do we see these fluctuations in the image memory? I can see now that probably this is involved with VMMap itself, because it happens only if I choose “launch & trace a new process” but not when “view a running process” and point to running exe fired from VS2010. Here is the screen of process “launched & traced”:

I observed also huge paging of memory, which started roughly with this decline in image (this paging nearly accelerated and quickly triggered RAM limit, that I have set to 2GB):

and here is a running process only “viewed” (runned from VS2010):

so maybe some issue subject to memory management of the .NET applications takes place here?
I am still waiting for my int to cross boundary of two complement.

well… I have to edit again: it turns out that as previously thought – the decreasing memory image effect is present when process is only viewed (not launched) too. Below is attached picture of the same process 10 minutes later (still waiting for turning int into negative):

and here it is:

so the biggest positive 2-complement on my machine is 2 147 483 647
and smallest negative is -2 147 483 648, what is easy to verify this way:

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

it gave me the same result: -2 147 483 648 and 2 147 483 647

back to the beginning
when I comment everything but the while() loop – the same thing happens: image is decreasing after process was running about 10 minutes, so it is not the useless code that cause this. but what?

Answer 1

Working set is largely under control of the operating system. What your code does is only one factor it considers when deciding whether to grow or trim your working set. Other factors include whether your application is in the foreground, how active it is, how greedy the heap algorithm is, how much memory pressure exists because of the demands of other processes, etc. This is by design.

The drops are probably related to Windows choosing to trim your working set. Since most of the code that was originally loaded was probably just for initialization and is not involved in the loop, it was simple for the OS to reclaim image pages based on a LRU-algorithm.

Notice that the working set allocated to the image size is not the only portion that was trimmed.