Blocking on allocation failure

Blocking on allocation failure - WTF?

Posted Mar 16, 2011 12:22 UTC (Wed) by epa (subscriber, #39769)
In reply to: Blocking on allocation failure - WTF? by giraffedata
Parent article: Delaying the OOM killer

Which specific case are you referring to?

I was referring to this from the article (my italics):

Should an out-of-memory situation come about, the processes in the affected group will simply block when attempting to allocate memory until the situation improves somehow.

Rather than blocking indefinitely on malloc(), it would make more sense to just return null when there is no new memory available. The application can then decide whether it wants to keep retrying indefinitely, report the error to the user, just die in a big cloud of smoke, or do something else like freeing some of its own data (e.g. the JVM could do a garbage collection pass). If malloc() just blocks forever, the app doesn't have that choice.

(Log in to post comments)

Blocking on allocation failure - WTF?

Posted Mar 16, 2011 15:22 UTC (Wed) by giraffedata (subscriber, #1954) [Link]

Should an out-of-memory situation come about, the processes in the affected group will simply block when attempting to allocate memory until the situation improves somehow.

Right. The process here does not block in malloc(). It blocks typically on a store instruction, but also on any of various system calls, such as open(). A malloc() at this time would succeed.

The process is attempting to allocate memory, as it is the process that is doing the system call or triggering the page fault in which kernel code attempts to allocate physical memory. malloc(), in contrast, doesn't, from the kernel's point of view, allocate memory — just addresses for it.

The article probably should have made a clearer distinction between memory as seen by user space code and memory as seen by the kernel.

Blocking on allocation failure - WTF?

Posted Mar 17, 2011 11:51 UTC (Thu) by epa (subscriber, #39769) [Link]

Thanks for the explanation.