Re: [Glib Internals] Request for help: a brief explaination of gmem's design

[Owen Taylor <otaylor redhat com>]

On Sat, 2004-01-03 at 17:24, Ryan McDougall wrote:
> Hello,
> 	I am steadily making my way through the source code, but I cant seem to
> get my head around what gmem is doing and why -- basically I can't
> visualize what its doing and why, which makes reading the code harder
> than it needs to be. I can guess some, but I'd really like to *know*.
> Part of the problem is that I don't think that the documentation uses
> consistent terminology, ex: constantly uses area, blocks, chunks,
> segments, etc. apparently interchangeably and without defining them.

I don't see 'blocks' used at all. The one use of 'segment' I see
looks like it means 'atom'

> Can anyone tell me if I've got this straight, and let me know what I'm
> missing?
> 
> Atoms are "indivisible", contiguous bytes designed to hold whole data
> types such as chars, ints, structs, etc.
> 
> Areas are like arrays of atoms, that is contiguous multiples of Atoms. 
> 
> Chunks are pools (if so I think GMemPool is a better name) of
> dis-contiguous sets of (possibly different sized) Areas held in a
> loop-up tree, designed to act as a memory management object that knows
> about which of its sub-areas are in use or can be freed.

 - All areas are the same size
 - The tree's only purpose is to map from atom to the area holding
   the atom. Which atoms are in use is tracked by the free_atoms
   list in the GMemChunk and the various fields of GMemArea.

Regards,
						Owen