On Solaris continous memory allocation doesn't reduced image size

Question

I have written one test program on Solaris sparc server and compiled it using Sun Studio

#include <iostream>

using namespace std;

int main()
{
    const int size =  9999;
    char *ptr[size];

    while(1)
    {
       for(int i = 0; i < size; i++)
       {
           ptr[i] = new char[2048];
       }
        for(int i = 0; i < size; i++)
        {
           delete[] ptr[i];
        }
    }
    return  9;
}

compiled it as
CC -m64 -g 

Now when I run it I can see that process size keeps on increasing and process crashes when it reached system memory limit. I traced it using truss and I can only see brk system calls. On searching some oracle sites I set LD_PRELOAD=libmapmalloc.so and then process size was constant. truss shows that this time it was using malloc to map anonymous memory pages.

On other hand I tried to see this behavioud on RHEL Linux 2.6 x86 box as well and there too it used truss but process size was constant.

I don't understand behaviour or Solaris in first case where it uses brk to increase size of data segment but when I do a delete it didn't reduced it. Can somebody please explain me why solaris is doing this way ?

So what different is linux doing here to keep process size constant as it also uses same system call.

Thanks Niraj Rathi

Answer 1

I read that article but as you can see that my allocation pattern is almost constant I am allocating around 20MB of memory and then freeing it and then again allocating 20MB of memory.

So in case Solaris libc is reusing freed memory then it should not call brk again and again and process size should remain constant but here it is growing continously and it seems like freed memory is never reused.

Thanks Niraj Rathi

Answer 2

Let me quote official oracle docs:

Note that after free() is executed, the freed space is made available for further allocation by the application and not returned to the system. Memory is returned to the system only when the application terminates.