space management

Benjamin Smedberg benjamin at smedbergs.us
Mon Jan 7 08:59:54 PST 2008


-----BEGIN PGP SIGNED MESSAGE-----
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 smedbergs.us
http://benjamin.smedbergs.us/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHglqKSSwGp5sTYNkRAvTYAKC2rN2VOLJhj/Sjx/ZdzrZE1nj+AgCgksz2
P8Mcnxh5rSKQIm/HqufYjkM=
=jyz1
-----END PGP SIGNATURE-----


More information about the Tamarin-devel mailing list