Re: ideas for returning memory to the OS

Enrico Weigelt wrote:
> That's one of the major reasons why mozilla is so fat

You mean in terms of codebase size?

Part of the problem, you see, is that OS libraries have a tendency to be broken. 
  In different ways on different OSes.  Or sometimes not broken but simply not 
behaving in the desired way (locale-insensitive floating point to string 
conversions comes to mind) Which means that writing cross-platform code involves 
either building in lots of exceptions for this brokenness or reimplementing 
parts of libc (see NSPR).

> and why socialist (top-down) economy only works on
> very small scale.

Actually, the reason for this is quite different.  It has more to do with so the 
model only working if there is broad agreement about the desired course of 
action and trust amongst all participants.  Both are hard to come by on large 
scales.

> The mozilla project itself should not take any influence to other
> projects like glibc. Of course, mozilla folks are welcomed to join
> these other projects, but then functioning as developers of these
> projects instead of moz there.

You didn't address the key point.  The typical situation is that a bug needs 
fixing.  It can be fixed in libc, or it can be fixed on the caller end by not 
using libc.  The next libc update that will include the fix it it gets fixed in 
libc today will ship in 18 months.  The caller needs to ship in 6 months.  What 
should the caller do?

I think everyone accepts that the best possible scenario is that the OS handles 
the things it's supposed to handle.  The problem is that in reality sometimes it 
doesn't.  One could even argue that in some areas (memory allocation, scheduler) 
it can't always behave optimally because different workloads require such wildly 
different behavior and because it doesn't have all the information needed to 
behave optimally (e.g. information about future lifetimes of allocations that 
the application may have).

> Or in business slang: "concentrate on your key competences".

Which means paying someone else to do the things you're not very good at. 
However, if you can't find such a someone else at a price you can afford, you 
might end up doing them yourself, even if the result is not as good as it could 
have been.

> On a qick look through the current seamonkey tree, I've seen
> at lot of bundled 3rd-party packages things which really should
> NOT belong there:

I'll let the people more familiar with some of these speak about why they're in 
the tree.  For cairo in particular it has to do with the fact that we don't 
necessarily want to be building against system cairo (which is often outdated 
right now).

>> I'm sure Robert's
>> comment was more about what to do on shorter timescale like for
>> Gecko 1.9 / FF 3.
> 
> Do you have an pointer to it ?

To Gecko 1.9?

-Boris