zbynek.winkler at gmail.com
Tue Jan 8 14:31:04 PST 2008
On 07/01/2008, Benjamin Smedberg <benjamin at smedbergs.us> wrote:
> |> 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
> memory available.
Interesting paper about GC and virtual memory
Garbage Collection without Paging
It describes a "bookmarking" GC. It scans pages before being evicted
from the memory and "bookmarks" all references so it does not have to
touch the page again.
I think that in the end, this is the right way to have GC and virtual
memory work together well. Until then the GC heap will be limited in
size by the available physical memory. Separating image data and other
large pointerless allocations will certainly help. The question is if
it is enough.
More information about the Tamarin-devel