No surprise on memory

[Tomeu Vizoso]

On Tue, Dec 16, 2008 at 15:29, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Tue, Dec 16, 2008 at 12:19 PM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>> I'm with Benjamin here, if the OOM killer kicked in soon enough and
>> activities were clearly marked as first candidates to be killed,
>> stability would be much much better.
>
> Combine that with Mac OS (pre X) style "estimated memory allocation"
> metadata for each activity and the user experience could perhaps even
> work.
>
> In terms of Ben's original email, what happens is a social problem,
> IMHO. Code that handles memory allocation failures is bloody hard to
> write -- because whatever decent handling you might want apply to the
> situation will also _need_ to allocate memory. So after many years of
> trying, the solution was  a combination of virtual memory and a lie:
> memory will never run out. And if it does, the process  will die badly
> because there is no way to die a nice death at that point.
>
> So we have some 15 years or more of programming with this "soft
> malloc" and "memory never ends" mantra. It works, and you can even
> request a ton of memory that doesn't exist... as long as you don't try
> to use it.
>
> Lots of nice tricks fall out of it - mmapping, etc - but again, the
> moment you actually use up memory, ouch.
>
> So IME the solution is to use very little memory - regardless of
> allocation. Malloc is just like a credit card.

Well, I wasn't trying to give a "solution", just suggested a "less
bad" way to fail. IMO, just trying to find the perfect solution while
not doing anything to improve what we have now is the worst of the
possibilities.

Regards,

Tomeu