tags:

views:

517

answers:

6

When I compile and run the following code :(using gcc on cygwin)

int *a = malloc(1024*1024*100*sizeof(int));
while(1)
;

The task manager in Windows XP shows memory usage by this process as 2232K, which according to me should have been around 400000K.

When I compile and run the following code :(using gcc on cygwin)

int *a = malloc(1024*1024*400*sizeof(int));
while(1)
;

the memory usage goes down to 1388K;

So, rather than showing an increase, it actually shows a decline.

What could explain this?

+7  A: 

You have allocated the memory, making it available, but have not yet used it (reading or writing from/to it). The memory manager may not have actually allocated the physical memory to your program yet, merely said that you can have it. If you write something across the memory you just allocated (e.g. filling it with 0's -- look at memset for that), I would expect that the memory usage would be more in line with what you expect.

Michael E
On Linux, this behaviour can be tweaked by setting `/proc/sys/vm/overcommit_memory to a value other than zero.
Michiel Buddingh'
Overcommit just tells the kernel to hand out more memory than it can guarantee it actually has. Memory will still be faulted in when it's actually used regardless of overcommit or not.
nos
+3  A: 

Unfortunately memory consumption is not as simple as a single. There are numerous ways in whtich memory needs to be tracked (and it differs between operating systems a bit).

For instance on Windows, here are some of the different memory usage types

  • Virtual Memory
  • Physical Memory
  • Commited memory
  • Reserved Memory
  • Shared Memory

Can you give us more details on exactly which number you are talking about?

One possible explanation is that you are looking at the physical memory usage of the process. The operating system will commonly allocate virtual memory address but not commit it to physical memory until it is actually used by your process.

One way to verify this would be to set up a for loop that wrote to every element in the array and then check the memory usage of the application.

JaredPar
+4  A: 

The second malloc would allocate 1600MiB (check your units). My guess is that this is more than your system can accommodate in a single process, so the second malloc fails. For some reason, you have a high overhead of other stuff in your application which causes memory usage to be high even though the malloc failed.

Print a to be certain.

Martin v. Löwis
+1, this is my guess too. Telling us what's the value of a after calling the malloc would say if that's the case or not.
eran
Value of a is a valid number(integer).
dta
A: 

The question of allocatable memory using malloc with gcc under cygwin is discussed at http://www.cygwin.com/cygwin-ug-net/setup-maxmem.html.

It would also be good to check the return from malloc.

mas
A: 

If you have optimization enabled and a is not acctually used, both the variable and the allocation will be removed. You can avoid this by declaring the variable as volatile.

Nothing changes by making the declaration volatile.
dta
A: 

http://en.wikipedia.org/wiki/Copy-on-write

Another use is in the calloc function. This can be implemented by having a page of physical memory filled with zeroes. When the memory is allocated, the pages returned all refer to the page of zeroes and are all marked as copy-on-write. This way, the amount of physical memory allocated for the process does not increase until data is written. This is typically only done for larger allocations.

Saradhi