Conference turris::digital_unix

9843.0. "malloc()/free() - Releasing memory to system" by RHETT::HICKS () Thu May 15 1997 17:03

I am working with a customer who has some questions about the ability of 
malloc()/free() to return memory to the available system pool.  This may be 
related to note 9605.*, but the program is in C (rather than FORTRAN) and the 
question is a little different.

By default, free() does not return memory to the system pool until the process 
exits.  In other words, if my program mallocs 30 MB, that memory is tied up by 
the process until it exits, even if the program executes a free().  My 
understanding is that this was a design decision implemented for performance 
reasons.

However, the malloc() man page seems to describe a way to override this 
behavior in the section labeled "Tuning Memory Allocation".  My customer wrote 
a short program (below) that implements this.  However, if I run the program 
and use swapon -s to monitor available memory while it is running, the free() 
does not seem to release the memory to the system.  (I am testing this under 
UNIX V4.0B).  

Under UNIX V3.2C there were two workarounds for this problem:

	1.  Execute a second free() call after the first, with a NULL
	    pointer as the arguement.

	2.  Use shared memory (shmget()/shmat()/shmdt()/shmdctl()) instead
	    of malloc()/free().

Under V4.0B, the first workaround no longer works.

Questions:

	1.  Does anyone see an error in this program or are we 
	    misinterpretting the malloc() man page?

	2.  Why was the first workaround (calling free() with a NULL
	    pointer) removed from Digital UNIX?

	3.  Can you suggest any other suitable workaround?


Thanks a lot for your help!

					Gary Hicks
					Realtime Expertise Center
					Atlanta CSC	

------------------------------------------------------------------------------

#include <stdlib.h>
#include <stdio.h>
#include <alloca.h>
#include <malloc.h>
#include <sys/types.h>

unsigned long __noshrink = 0;
size_t __minshrink = 16384;
double __minshrinkfactor = 0.001;
size_t __mingrow = 49152;
double __mingrowfactor = 0.1;
unsigned long __madvisor = 1;
unsigned long __small_buff = 0;
int __fast_free_max = 13;
unsigned long __sbrk_override = 0;
unsigned long __taso_mode = 0;

int bytes;
char *p;
char dummy;

main()
 {
  while(1)
  {
      printf("How many MB to malloc? ");
      scanf("%d", &bytes);
      if (!(p = (char *) malloc(bytes*1024*1024)))
         {
         printf("Outta memory...\n");
         perror("stack");
         exit(0);
         }
  
      printf("Malloc complete.\n");
      sleep(10);
      printf("About to free the memory...\n");
      free(p);
  }
 }
    

    Working... So far, it looks like sbrk is not freeing the memory.  I'll
    post more here when I find out more.
    
    -Al
    

    In current releases of DU, virtual address space is not released once
    acquired by sbrk() (which is what malloc() does while it can).  This
    means that swap space consumption will not go down if a large segment
    is malloc'd and then free'd.
    
    A user space work around for this would be to use mmap() when the
    application is allocating a large region, and use malloc() for the small
    mundane allocations.
    
    There is a kernel tuning parameter which will allow sbrk()'d memory to
    be deallocated.  It is only accessible by patching the kernel with dbx:
    
    >su
    # dbx -k /vmunix
    #assign old_obreak=0
    
    This will enable an sbrk behavior that was experimented with but not
    made the default due to performance degredation.  If the customer
    chooses to enable this behavior, the system performance may suffer.
    
    -Al
    

Al --

	Thank you very much for taking the time to work this and provide the update.
Two followup questions:

	1.  Do you anticipate this behavior changing in a future release?

	2.  If not, are there any plans to change the man page for malloc()/free()?

Thanks, again!!!

						Gary