Query regarding Dynamic Memory Allocation and deallocation

Hi,

I was going through a documentation on Memory management by process manager,where I came though a point that

“When the malloc library receives an allocation request that it can’t meet with its existing heap, the library requests additional physical memory from the process manager. These allocations are done in chunks called “arenas”. By default, the arena allocations are performed in 32 KB chunks. When memory is freed, the library merges adjacent free blocks within arenas and may, when appropriate, release an arena back to the system”

I need to understand that what exactly are the conditions or scenario which trigger the memory to be actually released to the system.Is it only on process termination? or I can force a memory release during runtime.

My second question is that if I am using the option “procnto -ml” to start the process manager,will it create a scenario that my process will continue to allocate memory as it requires (increase in size of heap allocated )but will actually return it to the system once it is terminated.

It’s almost always the case that when a process terminates, all allocated memory is returned to the system, so it is doubtful that the documentation referring to arenas being returned to the system is in reference to termination time.

My guess is that an arena would be returned automatically when you call free(). You could probably setup a test pretty easily that would confirm or deny this. If you want more control over allocation and deallocation, you might consider using the shm_open() and mmap() routines.

Taking a close look at the affect of starting procno -ml, I see that it doesn’t have much to do with your concerns. -ml causes all memory allocations in a process to be locked. What the docs seems to say about locking, is that it is an indication to the OS that it cannot reposition underlying physical memory in order to defragment it. You can still release memory, and it can still be used. If you have a process that will allocate and deallocate memory, and you want the system to be able to use the deallocated memory, you probably do not want to use -ml unless there is some underlying performance or hardware reason.

Hi,

Thanks for your reply.I have certain findings to share.
Regarding the release of chunks to system,I tried a sample application with elements added continously to a vector and after 10 elements were added I cleared the vector. I observed the Heap Allocation in Momentics (system Information) IDE. At startup my Application was allocated 64K. When elements were added memory incresed to say 1436K.When all the elements were deleted total heap reduced to 804K ;all of it was free though.So the chunnks are not totally released to the system.Is this behaviour expected?

Regarding the procnto option I have an application which reads and copies data from 1 file to another. This in turn increases the memory (heap) of devb-eide.The heap is not released even after terminating the application.This keeps on growing on every run of the application.

I tried doing the scenario by commenting -ml option of procnto but got the same results.So what could be the possible reasons for it.

Thanks.

Well based on that behavior, I’d guess there So why would I write to you at all?
is a more intelligent algorithm going on. Since you used 1400K, the system isn’t giving it all back. My guess is that the amount held in reserve is based on the maximum allocated. I got curious and created a simple test. I check memory allocation using “pidin mem” after loading a program, after allocating 1024 x some malloc’d amount and then after freeing it. Here are the results:

amount = 10,000 108K → 10M → 492K
amount = 50,000 108K → 64M → 876K
amount = 500,000 108K → 492M → 6012K

So it looks like there is a minimum left in reserve, but otherwise about 1/100th the maximum.

It could not reproduce this behavior. I created a 5 Meg file and copied it multiple times. My dev-eide heap was static at 157M. Is it possible that you have adjusted the file system cache size in some way. If you allocated it too small, you might be seeing it grow out of a desire to run efficiently.