[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gtk
Subject:    [gtk-list] Re: Revisting: glib/gtk memory (re)use
From:       Havoc Pennington <rhp () zirx ! pair ! com>
Date:       1999-07-11 0:55:00
[Download RAW message or body]


On Sat, 10 Jul 1999, Andy Kahn wrote:
> I was under the understanding that glib tries to intelligently reuse
> dynamically allocated memory.  That is, when you g_free() a hunk of
> memory, it gets placed on a free list so that it can possibly be
> recycled in the future when g_malloc() and friends are called.
> 
> (Yes, I am also aware that on most systems, the C runtime library will
> do the same for malloc()/free() calls, but this is not the issue
> here.  In this situation, I am referring strictly to glib and gtk.)
>

g_free() And g_malloc() are just wrappers for the C library malloc() and
free().
 
Glib does keep pools of allocated memory for equal-sized chunks (like list
nodes) because managing equal-sized chunks is much faster and easier than
a general allocator.

> Each time after completing 1000 iterations, I checked the memory use
> of the program and it keeps increasing.  So unless my eyes deceive me,
> my understanding must be flawed.  Can someone clear this up?
> 

Hard to say what's going on without a detailed debug session.
There might be a memory leak, or it may be that your C library isn't able
to return some memory for whatever reason, maybe there's fragmentation,
just hard to say.

Havoc


-- 
To unsubscribe: mail -s unsubscribe gtk-list-request@redhat.com < /dev/null

[prev in list] [next in list] [prev in thread] [next in thread]