zoned allocator [WAS: ideas for returning memory to the OS]

Enrico Weigelt <[email protected]> Fri, 14 Dec 2007 21:21:56 +0100
Newsgroups gmane.comp.mozilla.performance
Message-ID <[email protected]>
* Michiel van Leeuwen <[email protected]> wrote:

Hi folks,

> What would this mean for other applications that are based on xul, like 
> thunderbird and sunbird? Those usually have one window that exists for 
> the lifetime of the app. 

I'd suggest the term "viewer". So, eg. tabs within one window are
individual viewes. An plugin's draw area could also be treated as
it's own viewer.

In Oberon, an viewer is an (virtual) rectangular area, which someone
can paint to (a little bit like what's called DC in Windows).

Using an separate memory zone per viewer is an really interesting
idea. For example if you've got some unused (hidden) viewers laying
around, there're greater chances that it's swapped out, while those
of the actived (used) viewers can stay inside physical ram :)

But I also suggest, giving each viewer it's own thread. This would 
help locking issues w/ javascript, cpu intensive rendering, etc.
IMHO, it's acceptable if an individual viewer get's slowed down or 
locked up for a few seconds, as long as the other viewers aren't
affected. Ah, and memory leaks within one viewer would't be less
painful - once the viewer gets closed, evrything's cleaned up.

BTW: in Plan9 world, each viewer would get it's own process 
(talking to the others via 9P). So we wouldn't need an zoned 
allocator here and many locking issues would go away.

> Related to this: what about tabs that stay open a long time, but do 
> change? for example, webmail. I keep that open all day, but it reloads 
> all day. Would that also mean the memory won't be released?

hmm, raised an good point. maybe there could be an complete 
flush/recreate could be done after a while (maybe driven by
some statistics.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------