[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: RE: Functions and memory usage
- From: "Nick Trout" <ntrout@...>
- Date: Thu, 17 Oct 2002 18:30:58 -0700
> > 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.