[Interest] memory fragmentation?

[paulf at free.fr]

----- Original Message -----
> Am 21.08.12 18:04, schrieb Thiago Macieira:
> > On terça-feira, 21 de agosto de 2012 07.09.44, Jason H wrote:
> >> By returning out of memory, unrolling the stack, then at the top
> >> level
> >> displaying the error.
> >
> > Well, don't use for Qt.
> >
> > Qt code *will* crash in unpredictable ways under OOM circumstances.
> 
> Folks, I gave up checking for NULL pointers (C, malloc) or bad_alloc
> exceptions (new, C++) a long time ago. I remember a discussion
> several
> years ago (here on Qt interest?) about desktop memory managers
> actually
> never returning a NULL pointer (or throwing an exception) when they
> cannot allocate memory.

Hi

On Linux, the situation is fairly complicated. There are kernel options (see man malloc) to control overcommit. Normally, attempts to allocate will succeed unless there is "obviously" (in some heuristic way) not enough memory to satisfy the request, in which case malloc will return NULL or new will throw an exception. If there is enough memory, or the overcommit is "reasonable", then the allocation will succeed. As already mentioned, the memory is lazy allocated, and the pages are only really allocated when a page fault is caused when the memory is accessed. If the birds do come home to roost, and the amount of used memory approaches the total physical memory (RAM + swap) then

a) the OS will already be in a state of desperately trying to swap out pages
b) if that isn't enough, the OOM killer will do its dirty deed, with a heuristic that chooses an application with some combination of high memory use and low CPU time (this might not be the app that overcommitted, but it usually is). This will be a kill without the applicaton having any chance to recover.

I don't know if Windows or Mac OS X overcommit.

When you are in a situation where malloc/new are failing, then I think a lot depends on the size of the allocation request. If it is small (and thus you are on the edge of the limit of physical memory) then there is usually not a lot that you can do. The likelyhood is that, unless you can free some memory, you won't even be able to do much to exit cleanly. On the other hand if it is a "big" allocation that fails, then you probably do have enough memory to carry on and either exit cleanly or give a message like "Try closing some applications" or "Try increasing swap space" so that the user can retry the action.

A+
Paul