Re: ideas for returning memory to the OS

* Boris Zbarsky <[email protected]> wrote:
> 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...

There's much scientific work on that in the net. The Plan9 folks
are an good starting point.

If there were many smaller subsystems (in their own processes),
multiple allocator paradigms in one process wouldn't be required
that much, the OS could do more things, crashes of some single 
subsystem wouldn't take down the whole thing, etc, etc.

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

I really suggest some studies on Plan9. Although evryting is put 
into lots of small servlets, it's incredibly fast. They key point 
is dramatically reduced complexity (eg. very very few locking issues).
 
> > cope w/ actual storage formats, ldap, etc, within mozilla itself.
> 
> But code that's coping with them would still be running. 

Only if you really need it. For example, I normally don't need ldap,
but a few times I do. So I'd start the ldap-bookmark server only 
if I really need to.

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

Yes, it's more an issue of stability and reduced complexity.
The browser itself then never ever has to cope with binary 
compatibilty anymore and all the trouble with having all this
stuff in one process (eg. symbol conflicts, lockups, etc) are
immediately gone. We could even support several APIs/ABIs - 
one server per API/ABI. 

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

Of course, first the requirements have to be clear, then we 
can choose an proper interface.

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

Both. It's an completely separate library, maintained by an 
separate project (of course, moz folks are free to take part here).


BTW: I'm just talking about SOURCE. 
Binary stuff is totally of scope for me - that's the job of
the distros (ah, and some out-of-the-box win32 package of course
is also an distro).


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