treilly at adobe.com
Wed Jan 9 10:22:58 PST 2008
Fascinating stuff but we don't spend too much time worry about virtual memory paging. Our use cases trend towards tiny heaps that almost always fit inside resident memory. Although TC in the flash player has on the rare occasion run into virtual memory problems b/c of the JIT architecture and that's part of the reason TT exists.
I'm mostly concerned with:
1) understanding and reducing memory usage (why MMgc's memory profiler exists)
2) reducing fragmentation by using better allocator algorithms (MMgc could be better here)
3) encouraging experimentation by making tamarin's allocator pluggable
In my experience spending a couple days with a good memory profiler and optimizing the mutator results in more gain than you typically see with allocator algorithm choices. Further muddying the issue is that I've frequently been charged with doing both so the mutator and allocator can be specialized to compliment each other.
That said we can't foresee the places tamarin will go and it should come with one or more good general purpose allocators. Notably MMgc has never been taken to mobile phones, server or concurrent environments. This is changing and we're working to make the allocator used by tamarin pluggable. I'm not a believer in one universal allocator.
If we play our cards right researchers like this will maybe use Tamarin one day to conduct their GC research ;-)
From: Zbynek Winkler [mailto:zbynek.winkler at gmail.com]
Sent: Tue 1/8/2008 2:31 PM
To: Benjamin Smedberg
Cc: Thomas Reilly; tamarin-devel at mozilla.org
Subject: Re: space management
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