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/ ---------------------------------------------------------------------