Re: ideas for returning memory to the OS

Enrico Weigelt wrote:
> If there were many smaller subsystems (in their own processes),
> multiple allocator paradigms in one process wouldn't be required

This is true, yes.

> the OS could do more things

Doesn't follow.

> crashes of some single 
> subsystem wouldn't take down the whole thing, etc, etc.

Nothing to do with memory usage.

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

You talk about general architecture.  I'm raising a concrete example 
where this architecture won't work well, based on my knowledge of the 
code pattern in question.  I look forward to your code demonstrating 
this working fast on Plan9.

> Yes, it's more an issue of stability and reduced complexity.
> The browser itself then never ever has to cope with binary 
> compatibilty anymore

Who says this is a big worry with plug-ins now?  They use a well-defined 
API...  It's a C API, so ABI issues are not a problem.

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

Right.  I have yet to see you address the first requirement.

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

Why does it matter which CVS server the code lives in?

And not shipping a library that users don't have but that we depend on 
is simply not an option.

> BTW: I'm just talking about SOURCE. 

"Not shipped with Firefox" is talking about binary distribution.

> Binary stuff is totally of scope for me

In that case, I completely don't see your point.  You're advocating 
changing the actual physical bits occupied by source (without changing 
anything else) as the path to better code.  That's silly.

-Boris

P.S.  Probably my last post in this thread, since I feel that we've 
established that you have fundamentally different software development 
goals from the Mozilla Foundation.