malloc and free

[S S]

Hi

I am facing one problem while using my malloc(), I allocate 2GB
upfront in chunks of 4K using malloc. And then I free it immediately
assuming that free will not return back this memory to the system but
will keep it for future malloc use. But strangely, when I free it, I
see process size drastically goes down, meaning all memory has been
returned back to the system ?

I think malloc is also a memory manager which should keep all memory
with itself and should not return back to the system ? Am I not using
malloc the way it should be ?

Please help.

Thanks
SS

 

[Igmar Palsenberg]

I am facing one problem while using my malloc(), I allocate 2GB
upfront in chunks of 4K using malloc. And then I free it immediately
assuming that free will not return back this memory to the system but
will keep it for future malloc use. But strangely, when I free it, I
see process size drastically goes down, meaning all memory has been
returned back to the system ?

It's implementation dependant. The specs leave this up to the
implementor, so it's OS and OS version dependant.

I think malloc is also a memory manager which should keep all memory
with itself and should not return back to the system ? Am I not using
malloc the way it should be ?

Why should it ? It doesn't make sense : Applications that reserve memory
in (larger) amounts cause the OS to run low on memory. Some
implementations allow tuning, some don't. If you want it different :
write your own implementation



Igmar

 

[S S]

It's implementation dependant. The specs leave this up to the
implementor, so it's OS and OS version dependant.


Why should it ? It doesn't make sense : Applications that reserve memory
in (larger) amounts cause the OS to run low on memory. Some
implementations allow tuning, some don't. If you want it different :
write your own implementation

Igmar

Can I set some options so that it keeps memory and don't give back to
system ?

Thanks

 

[Keith Thompson]

There is some controversy on this point. The C standard says that
passing a pointer to free() causes the space pointed to to be
"deallocated, that is, made available for further allocation". Some
have argued that this implies that it must be kept by the
program/process/whatever that invoked free. But in any case, some
implementations work this way, and some don't.

[...]

Can I set some options so that it keeps memory and don't give back to
system ?

Maybe, but the C standard says nothing about any such options. You'll
need to consult the documentation for your system, or post in a
system-specific newsgroup or other forum.

One possibility might be to malloc() all your memory up front and then
*not* free it, using your own code (which you'll have to write) to
allocate memory from what you've already malloc()ed.

 

[S S]

There is some controversy on this point. The C standard says that
passing a pointer to free() causes the space pointed to to be
"deallocated, that is, made available for further allocation". Some
have argued that this implies that it must be kept by the
program/process/whatever that invoked free. But in any case, some
implementations work this way, and some don't.

[...]

Can I set some options so that it keeps memory and don't give back to
system ?

Maybe, but the C standard says nothing about any such options. You'll
need to consult the documentation for your system, or post in a
system-specific newsgroup or other forum.

One possibility might be to malloc() all your memory up front and then
*not* free it, using your own code (which you'll have to write) to
allocate memory from what you've already malloc()ed.

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

I am able to figure it out, there is option M_TRIM_THRESHOLD for
mallopt which you can set to -1 for getting the behavior I was asking
for

Thanks.

 

[Keith Thompson]

Maybe, but the C standard says nothing about any such options. You'll
need to consult the documentation for your system, or post in a
system-specific newsgroup or other forum.

[...]
I am able to figure it out, there is option M_TRIM_THRESHOLD for
mallopt which you can set to -1 for getting the behavior I was asking
for

Great. But be aware that using this makes your code non-portable. If
it doesn't *need* to be portable that's fine -- but you might find
some day that you need to run it on some other system that doesn't
provide M_TRIM_THRESHOLD.

 

[Antoninus Twink]

Can I set some options so that it keeps memory and don't give back to
system ?

You could investigate calling sbrk() yourself, instead of through
malloc.

 

[Martien Verbruggen]

You could investigate calling sbrk() yourself, instead of through
malloc.

Assuming that you're on a system that provides sbrk():

That is not a good idea, and there are other, better alternatives. If
you want to know why, ask on comp.unix.programmer.

If you're not on a system that provides it, it's certainly not a good
idea.

Martien

 

[Richard Tobin]

Can I set some options so that it keeps memory and don't give back to
system ?

[/QUOTE]

You could investigate calling sbrk() yourself, instead of through
malloc.

On a modern unix system, mmap() is likely to be a better way of getting
memory, unless you can guarantee that nothing else is going to allocate
memory.

-- Richard

 

[Nick Keighley]

Assuming that you're on a system that provides sbrk():

That is not a good idea, and there are other, better alternatives. If
you want to know why, ask on comp.unix.programmer.

If you're not on a system that provides it, it's certainly not a good
idea.

and this is a fine example of why giving off-topic answers
is a bad idea. Twink's suggestion to use sbrk() was actually
technically wrong and more by good luck we had someone on
comp.lang.c that knew that. On a Unix group there would
be a much smaller risk of this happening.

Apparently sbrk() is *specifically* excluded from the Posix
standard (which surprised me!).

--
Nick Keighley

Abuse of casting leads to abuse of the type system
leads to sloppy programming leads to
unreliably, even undefined, behaviour.
And that is the path to the dark side....
Richard Bos/John Hascall

 

[Kenneth Brody]

Hi

I am facing one problem while using my malloc(), I allocate 2GB
upfront in chunks of 4K using malloc. And then I free it immediately
assuming that free will not return back this memory to the system but
will keep it for future malloc use. But strangely, when I free it, I
see process size drastically goes down, meaning all memory has been
returned back to the system ?

I think malloc is also a memory manager which should keep all memory
with itself and should not return back to the system ? Am I not using
malloc the way it should be ?

An implementation is certainly free to do as you describe, and return
the memory to the O/S. (Well, actually, whether or not it's allowed
to has been discussed here several times. Suffice it to say that I
don't see a problem with it.)

Perhaps you could try not freeing the final malloc()'s return value,
and see if that would prevent the implementation from returning all
of the intervening memory to the O/S.

However, the exact behavior here will be implementation dependent.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[christian.bau]

I am facing one problem while using my malloc(), I allocate 2GB

upfront in chunks of 4K using malloc. And then I free it immediately
assuming that free will not return back this memory to the system but
will keep it for future malloc use. But strangely, when I free it, I
see process size drastically goes down, meaning all memory has been
returned back to the system ?

It can't find anything in the C Standard that says this isn't supposed
to happen.

Since the behaviour is fine according to the C Standard, the question
is: What are you actually trying to achieve?