malloc/free weird behaviour (Win32 / MsVC7)

Discussion in 'C Programming' started by Eric Nicolas, Oct 17, 2003.

  1. Eric Nicolas

    Eric Nicolas Guest

    Hi,

    I am just checking malloc/free behaviour. I thought that if I
    properly do one free() for each malloc()-ed block, the memory
    can actually be given back to the operating system. At least
    it is the case usually under Unix.

    Under Windows 2000, with Visual C++ 7 (.Net), I found that it
    is not the case : if I allocate many small blocks and then free
    them all, the total memory is not given back to the operating
    system.

    Below is my simple test program. If I look at the total virtual
    memory footprint, I see:
    - at start : 11 Mo
    - after alloc : 145 Mo
    - after free : 145 Mo, and it never goes back to 0.

    Anyone can explain me why ?

    Anyone has an idea how to give back memory to the operating
    system after having freed() all the blocks ? I have also tried
    a call to _heapmin(), with no more success.

    Please answer me on <>

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

    #include <windows.h>
    #include <vector>

    #define N 100000
    #define S 1000

    int main()
    {
    MessageBox(NULL, "Allocation...", "Test Program", MB_OK);

    {
    std::vector<void*> list;
    for(int i=0; i<N; ++i) list.push_back(malloc(S));

    MessageBox(NULL, "Free...", "Test Program", MB_OK);

    for(int i=0; i<N; ++i) free(list);
    } // This closing brace also frees the std::vector<>

    MessageBox(NULL, "Done", "Test Program", MB_OK);
    }
     
    Eric Nicolas, Oct 17, 2003
    #1
    1. Advertising

  2. Eric Nicolas

    Alan Balmer Guest

    On 17 Oct 2003 15:56:23 -0700, (Eric Nicolas)
    wrote:

    >Hi,
    >
    >I am just checking malloc/free behaviour. I thought that if I
    >properly do one free() for each malloc()-ed block, the memory
    >can actually be given back to the operating system. At least
    >it is the case usually under Unix.


    I wouldn't count on it even in Unix. The memory is made available for
    re-allocation by your program, but there's no requirement that it be
    made available to the OS before your program terminates.

    Some environments have a means of returning memory to the system, but
    those means are off-topic here. Try a Windows newsgroup.
    >

    <snip off-topic stuff>
    >Please answer me on <>
    >

    Sorry - post here, read here.

    --
    Al Balmer
    Balmer Consulting
     
    Alan Balmer, Oct 18, 2003
    #2
    1. Advertising

  3. On 17 Oct 2003 15:56:23 -0700, (Eric Nicolas) wrote:

    >I am just checking malloc/free behaviour. I thought that if I
    >properly do one free() for each malloc()-ed block, the memory
    >can actually be given back to the operating system. At least
    >it is the case usually under Unix.


    No - typically the C runtime allocates and frees in larger chunks to avoid
    OS allocation performance overheads.

    -- Mat.
     
    Mathew Hendry, Oct 18, 2003
    #3
  4. Eric Nicolas

    cody Guest

    "Eric Nicolas" <> schrieb im Newsbeitrag
    news:...
    > Hi,
    >
    > I am just checking malloc/free behaviour. I thought that if I
    > properly do one free() for each malloc()-ed block, the memory
    > can actually be given back to the operating system. At least
    > it is the case usually under Unix.
    >
    > Under Windows 2000, with Visual C++ 7 (.Net), I found that it
    > is not the case : if I allocate many small blocks and then free
    > them all, the total memory is not given back to the operating
    > system.
    >
    > Below is my simple test program. If I look at the total virtual
    > memory footprint, I see:
    > - at start : 11 Mo
    > - after alloc : 145 Mo
    > - after free : 145 Mo, and it never goes back to 0.
    >
    > Anyone can explain me why ?
    >
    > Anyone has an idea how to give back memory to the operating
    > system after having freed() all the blocks ? I have also tried
    > a call to _heapmin(), with no more success.
    >
    > Please answer me on <>
    >
    > -------------------------------------------------------
    >
    > #include <windows.h>
    > #include <vector>
    >
    > #define N 100000
    > #define S 1000
    >
    > int main()
    > {
    > MessageBox(NULL, "Allocation...", "Test Program", MB_OK);
    >
    > {
    > std::vector<void*> list;
    > for(int i=0; i<N; ++i) list.push_back(malloc(S));
    >
    > MessageBox(NULL, "Free...", "Test Program", MB_OK);
    >
    > for(int i=0; i<N; ++i) free(list);
    > } // This closing brace also frees the std::vector<>
    >
    > MessageBox(NULL, "Done", "Test Program", MB_OK);
    > }



    The problem could be that you should not use malloc/free in C++. use
    new/delete instead.


    --
    cody

    [Freeware, Games and Humor]
    www.deutronium.de.vu || www.deutronium.tk
     
    cody, Oct 18, 2003
    #4
  5. Eric Nicolas

    Mark Gordon Guest

    On 17 Oct 2003 15:56:23 -0700
    (Eric Nicolas) wrote:

    > Hi,
    >
    > I am just checking malloc/free behaviour. I thought that if I
    > properly do one free() for each malloc()-ed block, the memory
    > can actually be given back to the operating system. At least
    > it is the case usually under Unix.
    >
    > Under Windows 2000, with Visual C++ 7 (.Net), I found that it
    > is not the case : if I allocate many small blocks and then free
    > them all, the total memory is not given back to the operating
    > system.


    No, it makes it available for further allocations, not necessarily
    available to the OS.

    <snip>

    > Please answer me on <>


    No. Post here read the replies here.

    > #include <windows.h>


    OS specific and hence OT here.

    > #include <vector>


    C++ and hence OT here.

    <snip>

    Take your Windows specific questions over to a Windows group (MS has
    plenty) and any remaining C++ questions down the hall to comp.lang.c++
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
     
    Mark Gordon, Oct 18, 2003
    #5
  6. >I am just checking malloc/free behaviour. I thought that if I
    >properly do one free() for each malloc()-ed block, the memory
    >can actually be given back to the operating system. At least


    "the memory can actually be given back to the operating system"
    is equivalent to "the memory need not actually be given back to the
    operating system".

    >it is the case usually under Unix.


    I know of at least early one Unix variant where the only way of
    giving memory back to the OS was exit(). Calling sbrk() with a
    negative argument didn't actually release any memory. Calling
    sbrk() with a positive argument "allocated" memory previously
    "released". Even a "reasonable" OS that implements sbrk() won't
    take back a block too tiny to deal with until there is a decent
    size block to release. A "decent size" block is likely to
    correspond to the memory management page size on systems where that
    term actually has meaning.

    >Under Windows 2000, with Visual C++ 7 (.Net), I found that it
    >is not the case : if I allocate many small blocks and then free
    >them all, the total memory is not given back to the operating
    >system.


    The only thing remotely required to give memory back to the operating
    system is exit() (and possibly abort()), and even that isn't required
    by ANSI C but would be widely viewed as a bug in a multi-tasking
    operating system. Not releasing memory back to the OS is often
    viewed as an OPTIMIZATION. Like most optimizations, there are
    situations when it can backfire.

    Gordon L. Burditt
     
    Gordon Burditt, Oct 18, 2003
    #6
  7. Eric Nicolas

    Mark Gordon Guest

    On Sat, 18 Oct 2003 01:38:52 +0200
    "cody" <> wrote:

    > "Eric Nicolas" <> schrieb im Newsbeitrag
    > news:...
    > >
    > > I am just checking malloc/free behaviour. I thought that if I
    > > properly do one free() for each malloc()-ed block, the memory
    > > can actually be given back to the operating system. At least
    > > it is the case usually under Unix.


    <snip Windows & C++ specific stuff>

    > The problem could be that you should not use malloc/free in C++. use
    > new/delete instead.


    As I understand it you are correct that new/delete is to be preferred in
    C++, however it is unlikely to affect whether the memory is returned to
    the OS.

    However, this discussion belongs in comp.lang.c++ for the general
    question and a windows group for the specific behaviour of MS VC++
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
     
    Mark Gordon, Oct 18, 2003
    #7
  8. Eric Nicolas <> spoke thus:

    > I am just checking malloc/free behaviour. I thought that if I
    > properly do one free() for each malloc()-ed block, the memory
    > can actually be given back to the operating system. At least
    > it is the case usually under Unix.


    As other people have noted, this need not be the case. An implementation may
    do its own bookkeeping regarding used and free memory areas, and thus may well
    not return "free" memory to the operating system. Presumably your Win2k
    implementation is behaving in this manner.

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
     
    Christopher Benson-Manica, Oct 20, 2003
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    2
    Views:
    511
  2. John
    Replies:
    13
    Views:
    708
  3. ravi
    Replies:
    0
    Views:
    455
  4. Peter
    Replies:
    34
    Views:
    1,959
    Richard Tobin
    Oct 22, 2004
  5. Weird malloc behaviour

    , Jul 30, 2008, in forum: C Programming
    Replies:
    12
    Views:
    447
    Kenneth Brody
    Aug 1, 2008
Loading...

Share This Page