No surprise on memory

[Martin Langhoff]

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.

cheers,



m
-- 
 martin.langhoff at gmail.com
 martin at laptop.org -- School Server Architect
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff