Re: ideas for returning memory to the OS

On Dec 11, 4:06 am, "[email protected]" <[email protected]>
wrote:
> ===== Probably obsolete idea ======
>
> We don't want to map and unmap small chunks because that leads to VMA
> fragmentation which is really bad for performance. So we encounter the
> fragmentation problem again at a higher level.
>
> So here's the idea. Create "VM arenas" for lifetime-correlated VM
> allocations. Each VM arena has a set of blocks of reserved VM, each
> say 1MB in size. (I think on all major platforms we can make a large
> VM reservation and ensure the pages are only allocated lazily, say
> when the process touches them, so this won't waste RAM or swap.) Then
> associate one VM arena with each top-level window. Allocations whose
> lifetime is tied to the top-level window --- including chunk
> allocations for the content and frame arenas for documents inside the
> window --- are made from the window's VM arena. This would ensure that
> when the window is destroyed, all that memory can be unmapped,
> assuming no objects in the window's arenas are live. (We should track
> down any such stubborn objects and have them allocated elsewhere.) But
> address space lost due to fragmentation would be limited to some
> amount proportional to the number of open windows, and the number of
> mmap/munmap operations due to these VM arenas would be limited because
> we're working with 1MB chunks. It gives the easy-to-understand
> behaviour that closing windows returns memory to the OS.
>
> We could use "tab" instead of "top-level window" to scope the VM
> arenas if that makes more sense. And of course 1MB is a tunable
> parameter.

If you were to go this route, I think you would want to do it per tab
at most.  You would need to have a really good allocator working in
your VM arena to avoid it getting really fragmented over a long
lifetime for something like gmail.  I could see us trying to put more
allocations in to chunks like this and we should probably investigate
it but it would take a lot of work to get *all* of our allocations to
be per-tab.  We could certainly try putting the content and frame
arenas there.  We've also been discussing changing up some JS
allocations in a way that could allow them to share some of this space
as well.

That said, I think our best bet for 1.9 would be to take a look at how
often we have things holding on to a document past close and cycle
collection and see how often we can really throw a document away when
we close a tab or if we have things holding on to them.  We can use
mmap to allocate a single chunk for the arenas and get rid of the
numerous 8k mallocs that the PLArenaPool implementation does.  Using
mmap rather than lots of mallocs should be a bit faster initially,
although unless you try and explicitly reuse the mmap'd region for a
new arena you probably lose a perf win of reusing the 8k allocations
that are most likely in the heap's freelist.  Or maybe you win because
you don't fragment the heap as much.  Hard to say -- we should test
it.  Either way, the content heap patch very significantly reduces the
number of mallocs we do which should help reduce our fragmentation a
lot.