space management

Benjamin Smedberg benjamin at
Fri Jan 4 12:59:34 PST 2008

Hash: SHA1

Thomas Reilly wrote:

> There's also trade offs we're making that might not work well for other
> clients.   For instance right now we support 8b to 16kb allocations using
> the same approach and either don't support larger allocations (think
> embedded device) or bail to direct to OS solution (ie mmap).   The lot
> abstraction (which is allocator independent) plays a large role here
> obviously.   We also have 8b of internal fragmentation per allocation
> which may be a problem, I think that can be brought down to 4b if we
> ditch DRC but we're not too worried about it because we also have taken
> steps in the VM to avoid lots of little allocations.

I'm going to have a long and rambly set of concerns here: treilly are you in
the MV area? I will be in town Jan 29-31... is there a chance we could meet
up to discuss this?

What kind of measurements are you doing for your current work?

What are your plans for finalizers? I know of one generic way to avoid
finalizers using a presweep hook, maintaining an internal linked list
per-type of objects that need cleanup behaviors, but that uses a word
per-object for the pointer: currently finalized XPCOM objects in Mozilla
don't have any overhead, because they piggyback on the interface vtable that
we're using anyway. Is your concern with finalizers complexity in the
allocation engine, or the leaky C++ abstraction required by the finalizer
vtable, or something else?

Does the allocator treat GC objects and explicit allocations the same? Here
is my major concern: research indicates [1] that paging during GC
drastically degrades performance.

I'm convinced (in theory, without measured data) that we want to limit the
GC heap size to all fit in physical memory. If we mix GC objects and
explicitly allocated objects, that will inflate the size of the GC heap with
many potentially large objects: image bitmaps, video data, network data, etc.

It seems that separating out the large non-GC objects so that they are in
separate OS pages which don't need to be touched during GC is pretty
important... but I'm talking without solid measurements to back me up.

This may not be an issue on some small devices which only have physical
memory and not virtual memory.

Mozilla will not be able to switch much of its code to the lot abstraction
immediately (and I'm a little skeptical about the abstraction in general)...
if the primary reason for lots is to avoid memory fragmentation, couldn't we
just use a better allocator? Hiding all memory access to a large object
behind a lot abstraction layer seems like a pretty hefty price to pay.

- --BDS


- --

Benjamin Smedberg
Platform Guru
Mozilla Corporation
benjamin at
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla -


More information about the Tamarin-devel mailing list