Re: ideas for returning memory to the OS

Enrico Weigelt wrote:
> For example, memory management problems were far from being that 
> bad if moz would be split off into several smaller subsystems with 
> tiny and strict interfaces

I'd like to see some data showing that this is in fact true...

> which are only started on demand.

It turns out that most parts are needed very soon in any reasonable 
browsing session.  Bookmarks/history used to in fact be in their own 
library; moving them into a library with some other things actually 
reduced startup time and improved memory consumption.

> If this would be done by an separate server

[talking about bookmarks/history]
Then your pageloads would slow to a crawl as you context-switched on 
every style resolution for a link.  Unless the client cached results in 
a serious way, which automatically increases the memory consumption.

> cope w/ actual storage formats, ldap, etc, within mozilla itself.

But code that's coping with them would still be running.  Where's the 
memory win?

> Another important point is moving out plugins to their own
> processes.

This is a good idea for various reasons, but not necessarily a memory 
win, except insofar as it prevents plug-in leaks from permanently 
leaking the browser process's memory.

> Right. But all this should happen within (and hidden behind the 
> interfaces of) some dedicated memory management library.

You're talking about totally different things here.  There are two 
questions:

1)  What functionality is needed?
2)  What is the API to expose it?

You're talking about (2) before (1) has been decided.  That's putting 
the cart before the horse.

> And this lib won't be directly included within the moz tree, 
> but instead *imported*.

Meaning what?  Not pulled from mozilla CVS?  Not shipped as part of 
Firefox?  Something else?

-Boris