| |||||||||||||
Blocking on allocation failure - WTF?Blocking on allocation failure - WTF?Posted Mar 10, 2011 14:42 UTC (Thu) by epa (subscriber, #39769)In reply to: Blocking on allocation failure - WTF? by Tuna-Fish Parent article: Delaying the OOM killer
How would you pass that information?By returning null, as is the documented interface for malloc(). Any memory access can fail due to lack of memory -- how do you handle that in userspace?This is true, you can get errors on accessing memory that was previously 'allocated'. But that's not a reason for doing the wrong thing in this specific case. If it is quite certain that the memory isn't available, why not return that to the application using the documented interface? If the app wants to just sleep waiting for memory to become available, it can do so at its own choice.
(Log in to post comments)
Blocking on allocation failure - WTF? Posted Mar 12, 2011 0:15 UTC (Sat) by giraffedata (subscriber, #1954) [Link] This is true, you can get errors on accessing memory that was previously 'allocated'. But that's not a reason for doing the wrong thing in this specific case. Which specific case are you referring to? The article is about the OOM killer, which comes into play when a process accesses memory (for example, executes a STORE instruction), not when a process does malloc(). In that case, how would you have the kernel notify the application program? And even if we're talking about a case where the the user space program could be told that the system is out of memory and given the option to do something other than block, that wouldn't be acceptable because the user space programs have already been written. We want to do the best possible thing given existing programs. And even if we were talking about programs not yet written, there's something to be said for freeing the coder from worrying about these tedious, extremely rare situations.
Blocking on allocation failure - WTF? Posted Mar 16, 2011 12:22 UTC (Wed) by epa (subscriber, #39769) [Link] 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.
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.
|
|||||||||||||