space management

Thomas Reilly treilly at
Wed Jan 9 10:32:36 PST 2008

I couldn't help but laugh out loud when I started experiencing this crash on Firefox shutdown recently after this thread transpired:

0   libnss3.dylib                 	0x00e5d278 NSSRWLock_LockRead + 18
1   libnss3.dylib                 	0x00e4a83b PK11_GetAllTokens + 91
2   libnss3.dylib                 	0x00e4abd9 PK11_GetBestSlotMultiple + 452
3   libnss3.dylib                 	0x00e4ac29 PK11_GetBestSlot + 32
4   libnss3.dylib                 	0x00e388bf PK11_CreateDigestContext + 37
5   libnss3.dylib                 	0x00e2c496 CERT_DecodeCRLDistributionPoints + 559
6   libnss3.dylib                 	0x00e2c654 HASH_Create + 60
7   org.mozilla.firefox           	0x0004adc0 nsCryptoHash::~nsCryptoHash() + 66
8   libxpcom_core.dylib           	0x00d208d9 XPTC_InvokeByIndex + 81
9   org.mozilla.firefox           	0x00370ee7 XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 743
10  org.mozilla.firefox           	0x00363187 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned int, long*, long*) + 261

My salient point remains, finalization/shutdown is a tough area to get right and determinate mutator handled finalization is a better way to go than indeterminate GC dependent finalization.  I think a 4 byte overhead linked list is a small price to pay for stability/determinism but there's way to optimize that space away if its really a problem.

Something that will move the discussion forward I think is to talk about concrete finalization use cases/requirements.  I've offered up the need for flash to serialization object graphs to files/sockets as part of its shared object functionality which works much nicer with a list traversal fired from presweep.  Care to offer up an example from Moz/Firefox?

-----Original Message-----
From: Benjamin Smedberg [mailto:benjamin at]
Sent: Mon 1/7/2008 8:59 AM
To: Thomas Reilly
Cc: Stuart Parmenter; tamarin-devel at
Subject: Re: space management
Hash: SHA1

Thomas Reilly wrote:

| TT is almost at the point where it doesn't use them at all and it
| really doesn't use them at all in my private branch.  If you
| think about it I there's no real difference between a linked list
| presweep approach to finalization and GC provided finalization.
| Its just a matter of who's doing the work, the collector or the
| mutator.  Thoughts:

This is not true, at least in Mozilla's case: the linked-list approach
requires an extra word per-object for most objects. Currently whether an
object is finalized is stored in allocator flag bits, and the object has a
vtable. But since Mozilla objects already have a vtable, which can inherit
from MMgc::GCFinalizable, a finalized object has no space overhead compared
with a non-finalized object.

If you switch to a linked-list approach, Mozilla objects have to pay for the
vtable *and* a linked list pointer.

|> 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.
| The way the allocator works is largely up in the air, remember TT
| is still in prototype  mode and there's still a lot of leeway.  But
| the answer is yes they are stored together and that we think we only
| want it this way for minimal/embedded configs.
| There's two things to worry about, # of cache lines brought in
| and hitting too many pages causing TLB misses or soft page
| faults (let me know if my terminology isn't right).  Putting a

I'm much less worried about processor cache misses than I am paged memory...
I'm pretty sure a single virtual-memory page fault would completely dominate
any wins you get from better locality in general.

Mozilla won't have good statistics about the ratio of managed/unmanaged
memory in use for a month at least, so it's hard to say whether this will be
a real issue: but if managed memory is only 60% of our total memory
allocation, segregating the managed and unmanaged memory could help avoid
page faults during GC and allow total memory used to grow beyond physical
memory available.

| What if it greatly reduces fragmentation and memory usage and the
| performance penalties can be addressed?  How many allocations
| does Mozilla make that are greater than 32kb?  What are they?

It's not really a question of which allocations *are* greater than 32k,
although I'm hoping Stuart pipes up with some numbers (image data
certainly). Any allocation which *could be* more than 32k has to hide data
access behind the abstraction layer.

- --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