treilly at adobe.com
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?
From: Benjamin Smedberg [mailto:benjamin at smedbergs.us]
Sent: Mon 1/7/2008 8:59 AM
To: Thomas Reilly
Cc: Stuart Parmenter; tamarin-devel at mozilla.org
Subject: Re: space management
-----BEGIN PGP SIGNED MESSAGE-----
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  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
| 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.
benjamin at smedbergs.us
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Tamarin-devel