Memory reduction

Question

I run 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 I observe such a decrease in image memory (purple): Legend:

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

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

This is strange: look what happened after 30,000 iterations. Why do we see these fluctuations in the image memory? Now I see that this is probably due to VMMap itself, because it only happens if I select "start and monitor a new process", but not "view the running process" and indicate that exe has been started from VS2010. Here is the running and tracked process screen:

I also observed a huge memory paging that started around this image reduction (this paging almost accelerated and quickly caused the RAM limitation that I set to 2 GB): and only “view” works here (launched VS2010):

so maybe some kind of memory management problem for .NET applications takes place here? I am still waiting for my int to cross the border of two additions.

well ... I need to edit it again: it turns out that, as previously thought, the effect of reducing the memory effect is present when the process is viewed (not running). Below is an image of the same process after 10 minutes (still waiting for the int to turn negative):

and here it is:

therefore, the largest positive 2-component on my machine is 2,147,483,647 and the smallest minus -2,147,483,648, which is easy to verify as follows:

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

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

back to the beginning when I comment on everything except the while () loop, the same thing happens: the image is reduced after the process runs for about 10 minutes, so this is not useless code that causes this. but what?

Answer 1

The working set is mainly controlled by the operating system. What your code does is just one factor that it takes into account when deciding whether to grow or crop its 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 there is due to the requirements of other processes, etc. This is by design.

The drops are probably related to the choice of Windows to crop your working set. Since most of the source code that was originally downloaded was probably only for initialization and was not involved in the loop, it was easy for the OS to restore image pages based on the LRU algorithm.

Note that the working set allocated to the image size is not the only part that has been cropped.