Re: ideas for returning memory to the OS

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

Great that we can at least agree here :)
 
> > the OS could do more things
> 
> Doesn't follow.

Maybe I'd should make it more clear:

If we have all those things, we currently would put to their own
memory zone, would run in their own process, we don't need the
additional complexity of an zoned allocated (plain malloc() maybe
would be fine). And a lot of multiplexing/queueing issues can
also be done by the OS' filesystem/ipc.

;-P

I really suggest, taking a large cup of hot coffee and read the
a little bit from Plan9/PlanB research. It's really amazing,
how easy *and* fast things can be, if you consequently break
down complexity that dramatically :)
Yeah, I've always been sceptical about micro kernels and similar
architectures, but Plan9 really convinced me.

In fact, in today's software development we're wasting really
much resources (machine and human) on stupid problems, which do
not need to exist at all :)

> > crashes of some single 
> > subsystem wouldn't take down the whole thing, etc, etc.
> 
> Nothing to do with memory usage.

Right. If you want to talk *only* about memory usage, it would
be out of scope, but IMHO we shouldn't loose the view on the
whole things.

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

Please, let's go through these things one by one. 
If it becomes OT, I'd suggest moving this discussion an more
appropriate list.

Yes, I know, this doesn't help in fixing current bugs, but I'm
really interested in long term strategies.

BTW: there's an dedicated group for moving Plan9 concepts to
classic software development:

* http://freebc.metux.de/groups/9forge

You can subscribe to mailfeeds and also post directly via mail :)
(So we've got web board and mailinglist together)

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

Right, but the problem is: not every system provides that ABI.
(Think of 64bit systems or even completely different archs).

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

Aehm, I was talking about the mozilla source tree.
Of course, it's irrelevant if there are other cvs modules on
the same server/respository :)

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

That's an clearly distro issue. The distro maintainer is responsible
for putting evrything together to make it run out-of-the-box on some
certain target. Of course the self-contained end-user packages are
also their own distro ;-P

> > BTW: I'm just talking about SOURCE. 
> 
> "Not shipped with Firefox" is talking about binary distribution.

Sorry, we had a great misunderstanding here. I'm ONLY referring to
SOURCE. Binary packages are, per definition, distro issues. 
(as already said).

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

No, it's not silly. It moves out the maintenance of 3rd party 
packages and allows making the build process less complex
(eg. reduces the need of multi-stage builds).


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