On Tue, Dec 16, 2008 at 12:19 PM, Tomeu Vizoso <[email protected]> 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 -- [email protected] [email protected] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
