Minimum 504Kb Memory Usage

Question

On doing some experiments whilst learning C, I've come across something odd. This is my program:

int main(void) {sleep(5);}

When it is compiled, the file size of the executable is 8496 bytes (in comparison to the 26 byte source!) This is understandable as sleep is called and the instructions for calling that are written in the executable. Another point to make is that without the sleep, the executable becomes 4312 bytes.

int main(void) {}

My main question is what happens when the first program is run. I'm using clang to compile and Mac OS X to run it. The result (according to Activity Monitor) is that the program uses 504KB of "real memory". Why is it so big when the program is just 4KB? I am assuming that the executable is loaded into memory but I haven't done anything apart from a sleep call. Why does my program need 500KB to sleep for five seconds?

By the way, the reason I'm using sleep is to be able to catch the amount of memory being used using Activity Monitor in the first place.

I ask simply out of curiosity, cheers!

Answer 1

When you compile a C program it is linked into an executable. Even though your program is very small it will link to the C runtime which will include some additional code. There may be some error handling and this error handling may write to the console and this code may include sprintf which adds some footprint to your application. You can request the linker to produce a map of the code in your executable to see what is actually included.

Also, an executable file contains more than machine code. There will be various tables for data and dynamic linking which will increase the size of the executable and there may also be some wasted space because the various parts are stored in blocks.

The C runtime will initialize before main is called and this will result in both some code being loaded (e.g. by dynamically linking to various operating system features) as well as memory being allocated for a a heap, a stack for each thread and probably also some static data. Not all of this data may show as "real memory" - the default stack size on OS X appears to be 8 MB and your application is still using much less than this.

Answer 2

In this case I suppose the size difference you've observed is significantly caused by dynamic linking.

Linkers usually don't place common code into the executable binaries, instead they reserve the information and the code would be loaded when the binary is loaded. Here those common code is stored in files called shared object(SO) or dynamically linked library(DLL).

[pengyu@GLaDOS temp]$ cat test.c
int main(void) {sleep(5);}
[pengyu@GLaDOS temp]$ gcc test.c
[pengyu@GLaDOS temp]$ du -h --apparent-size a.out
6.6K    a.out
[pengyu@GLaDOS temp]$ gcc test.c -static
[pengyu@GLaDOS temp]$ du -h --apparent-size a.out
807K    a.out

ALso, here I'm listing what are there in the memory of a process:

• There're necessary dynamic libraries to be loaded in:

  Here ldd gives the result of dynamic libraries to be loaded when invoking the binary. These libraries locates in the part where it's obtained by calling the mmap system call.

  [pengyu@GLaDOS temp]$ cat test.c
  int main(void) {sleep(5);}
  [pengyu@GLaDOS temp]$ gcc test.c
  [pengyu@GLaDOS temp]$ ldd ./a.out
  linux-vdso.so.1 (0x00007fff576df000)
  libc.so.6 => /usr/lib/libc.so.6 (0x00007f547a212000)
  /lib64/ld-linux-x86-64.so.2 (0x00007f547a5bd000)
  

• There're sections like .data, .code to be allocated for data from your binary file.

  This part exists in the binary executable, so the size is supposed to be no lager than the file itself. Contents copied at the loading stage of a executable binary.

• There're sections like .bss and also the stack zone to be allocated for dynamically use during execution of the program.

  This part does not exist in the binary executable, so the size could be quite large without being affected by size of the file itself.