benjamin at smedbergs.us
Mon Jan 7 08:59:54 PST 2008
-----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