RE: Functions and memory usage

["Nick Trout" <ntrout@...>]

> > What happens when you deallocate/free an object?
> Instead of keeping track of the pages we keep a linked list 
> of feer blocks for every chunk size,
> because they are "empty" we use the block himself as node of 
> the linked list so no memory overhead.
> When we create a page, the address of the first chunk is 
> aligned in a way that allow us to 
> retrieve the page start address from the chunk address.The 
> page is ref counted(first 4 bytes).
> When we allocate a chunk we pop it from the free list and add 
> a reference to the page.
> When we free we put it back in the free list and we decrement 
> the reference if is 0 we free the page.

So you could have lots of pages allocated that are half full? Eg. If
longer living objects were mixed with shorter living ones. I don't
suppose there is an easy way around this. I like the fact that
fragmentation of the similar size objects is localised. Given that you
have a general system though and the allocation could go in any of the
pages I wonder if it would be more efficient for subsystems to be able
to create their own pages. This might help with cache coherence? Eg. If
a particle system allocated X pages its update and rendering may
benefit. The other benefit may be that if you kill it then all its pages
disappear and you may not have a number of them lingering because they
have a few chunks still used in them. I think there is a danger in your
system that after a time you might end up with lots of pages allocated
containing a few chunks, and fragmentation will become a problem? 

There are lots of factors. Your method works for your game and platform
but I'm not sure how well it would work on a more restricted system with
a very free flowing environment.

> I've took a quick look at dlmalloc, it looks not so far from 
> our approach exept for the implementation.
> I'll test it.

That would be great. 

Regards,
Nick