Re: ideas for returning memory to the OS

[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.

This idea only obsolete in the sense that it's what the current plan is :)

So ideally I would like to have one arena per "window" (see below for
definition of window). We should try to stick as many objects that have
lifetimes similar to the window into that arena. This includes things
such as DOM nodes, JS objects, layout frames, style structs, etc etc.
Once the window goes away we'll in most cases delete all objects in the
arena, and the arena can go away.

Unfortunately I don't think we'll reasonably be able to stick
*everything* related to a window into that arena. For example a lot of
objects are holding strings, we most likely will not want to pass
pointers to the arena into every call to the string classes and pass in
a pointer to what pool they should use. Nor to every nsVoidArray call
and tell it which pool to use for its internal buffer.

What I think we should do is to move as much as possible into the arena,
and do profiles to see where it makes sense to do so. I.e. which
codepaths cause large amounts of allocations. The remaining objects
should go into the default heap which will act as an 'other' pool.
Eventually we'll figure out which objects are worth pushing into the
per-window pools and which are fine as-is.

So the definition of "window". Basically we'll want one pool per tab.
But use a new pool every time the user navigates to a new toplevel
document in that tab. This means that if you are staying at a toplevel 
document, but do a lot of browsing inside an iframe of that document, 
we'll never end up freeing the arena for that document.

I don't think this is a huge problem though. It's probably rare that you 
stay forever on a page, but browse around a lot in a subframe of that 
page. Also, the alternative scares me more actually. If we use separate 
arenas for subframes, we'll behave poorly if someone uses iframes to 
load documents, and then moves nodes out of those documents into the 
main page. I'd imagine this is something that AJAX pages do. Granted, 
this probably isn't very common either, so maybe it's not a big problem.

So to get all this to happen I think we need to work in stages. We've 
for a long time had an arena for layout stuff like frames and 
stylecontexts (right?). There is a patch in bug 403830 to move a pile of 
content stuff into an arena.

Once we have that we should try to use the same arena where needed, and 
probably also make more things use arenas.

/ Jonas