Re: memory not freed up?

This seems simple but it is not !

The problem probably comes from the global use of the computer memory.
Languages like C and F90 allocate fixed parts of the memory. Then, when
a lot of allocate/deallocate (or malloc/free) instructions are
performed, then the memory becomes a sort of chain, ramaining allocated
objects being separated by holes (memory deallocated previously). When
allocating a new large amount of memory, the compiler has to choice
between selecting a zone which has never been allocated before, or
finding a hole just large enough to contain the requirement.

By experience, (I wrote a long time ago a library to manage memory in
F77 programs), finding a hole may be an expensive task. So, sometimes,
holes become dead zones especially if several independent programs are
running together.

In my library, I decided to make possible to move arrays from time to
time in order to suppress dead zones. But such a technique assumes a
double pointer association, the "pointer" managed by programs pointing
to the address of the address of the memory zone. Then, moving a memory
zone does not change the first address (only the second one).

In a language like JAVA, the garbage collector is authorized to move
objects. This is one of the reasons which make the coupling java->C or
java->Fortran not obvious.

.

Relevant Pages

  • Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
    ... With that .config, and without this patch: ... Too many memory regions, truncating ... I still have not reproduced the problem locally, but I don't have an x86_64 with so many holes either. ... DMA zone: 4096 pages, LIFO batch:0 ...
    (Linux-Kernel)
  • Re: Is there a maximum contiguous memory allocation?
    ... but could ALLOCATE it! ... allocate it if I had 2GB of physical memory! ... the amount of physical memory I have installed. ... Note that you can use raw VirtualAlloc to improve your ...
    (microsoft.public.vc.mfc)
  • Tru64 issues with Infinite limits
    ... An automated test in my nightly build was failing due to Out of Memory ... Cannot allocate block 146 ...
    (comp.unix.tru64)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: run-time vs compile-time
    ... > offset related to some location (like stack base) somewhere. ... > offset from heap to pi. ... When you allocate an int on the heap, it is allocated at address 1. ... application has a given amount of memory it can use as it wishes. ...
    (comp.lang.cpp)