18 ms·

On OOM, what should happen other than a hard abort? On most VM systems, malloc and friends oversubscribe what is actually available. What possible recovery mech

On OOM, what should happen other than a hard abort? On most VM systems, malloc and friends oversubscribe what is actually available. What possible recovery mechanism can you implement to prevent this from happening?

quotemstr 11y ago
> On OOM, what should happen other than a hard abort? On a web server, 500? On a document editor? "Sorry, couldn't add attachment". What to do in response to error is application-specific. My point is that memory is not special and there is no reason to treat memory errors differently from other errors. You wouldn't abort if you run out of disk space. > On most VM systems, malloc and friends oversubscribe what is actually available. Windows is a common non-overcommit OS. Even on overcommit systems, it's possible to exhaust a process's virtual address space. (Overcommit systems also have ulimit -v.) If you do run out of either address space or commit, it's frequently the case that you can just stop what you were doing and display an out-of-memory dialog. The process of "stop what you were doing" can certainly free enough memory to keep going.
- mondoshawan 11y ago
  http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm So Herb Sutter mostly agrees with your view, but my question is a corollary, and something he touches on: how do you keep going if you stop what you were doing? The process of recovering is not straightforward, and if you have threads running, that process is utter chaos, if not outright impossible in some languages. Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Either way, the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first place -- which, incidentally, leaves the user stuck in exactly the same place as if your application aborted. The big idea here is that the OOM condition may not be because of your application.
  - quotemstr 11y ago
    > how do you keep going if you stop what you were doing You unwind. If you have threads, you reliably signal for them to stop (using resources you've set aside for the task), then you join the threads and continue unwinding. I think it's perfectly straightforward. > Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Most serious operating systems have a way to say "run this process in this special environment where it can't allocate more than X MB of memory". (Some examples are NT Job objects, FreeBSD jails, Linux cgroups, and plain old ulimit.) In this kind of environment, you can certainly run up against limits for your process without the system having been rendered unusable. > because the system is already hosed to the point where a small memory allocation will fail Absolutely not the case. Imagine a state where a 100MB allocation (e.g., for an image) might fail (say, due to virtual address space fragmentation), but a 10 byte allocation would work just fine. The same principle applies to system commit considered globally instead of virtual address space considered per-process. > the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first plac If that's the case, the application is just badly coded. Memory is not special. It's just another resource. If you can't keep track of resources and release them when they're unneeded (as they would be after an error), you're doing something wrong. > http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm That article is factually incorrect. Sutter claims that "On...Linux, memory allocation always succeeds. Full stop." That's false, as a ten-line C program that calls malloc in a loop can demonstrate. You eventually run out of address space, especially in a 32-bit process. (There's a very popular overwhelmingly 32-bit Linux distribution out there called Android. You may have heard of it.) Sutter also claims that on other operating systems, overcommit is configurable. It's in fact configurable under Linux too. Linux can run in sane, non-overcommitting mode.

quotemstr 11y ago

> On OOM, what should happen other than a hard abort? On a web server, 500? On a document editor? "Sorry, couldn't add attachment". What to do in response to error is application-specific. My point is that memory is not special and there is no reason to treat memory errors differently from other errors. You wouldn't abort if you run out of disk space. > On most VM systems, malloc and friends oversubscribe what is actually available. Windows is a common non-overcommit OS. Even on overcommit systems, it's possible to exhaust a process's virtual address space. (Overcommit systems also have ulimit -v.) If you do run out of either address space or commit, it's frequently the case that you can just stop what you were doing and display an out-of-memory dialog. The process of "stop what you were doing" can certainly free enough memory to keep going.

mondoshawan 11y ago
http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm So Herb Sutter mostly agrees with your view, but my question is a corollary, and something he touches on: how do you keep going if you stop what you were doing? The process of recovering is not straightforward, and if you have threads running, that process is utter chaos, if not outright impossible in some languages. Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Either way, the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first place -- which, incidentally, leaves the user stuck in exactly the same place as if your application aborted. The big idea here is that the OOM condition may not be because of your application.
- quotemstr 11y ago
  > how do you keep going if you stop what you were doing You unwind. If you have threads, you reliably signal for them to stop (using resources you've set aside for the task), then you join the threads and continue unwinding. I think it's perfectly straightforward. > Even on non overcommit systems, the user finding another way to work around a memory failure is useless because the system is already hosed to the point where a small memory allocation will fail. Most serious operating systems have a way to say "run this process in this special environment where it can't allocate more than X MB of memory". (Some examples are NT Job objects, FreeBSD jails, Linux cgroups, and plain old ulimit.) In this kind of environment, you can certainly run up against limits for your process without the system having been rendered unusable. > because the system is already hosed to the point where a small memory allocation will fail Absolutely not the case. Imagine a state where a 100MB allocation (e.g., for an image) might fail (say, due to virtual address space fragmentation), but a 10 byte allocation would work just fine. The same principle applies to system commit considered globally instead of virtual address space considered per-process. > the situation is so bad that the user does not have the ability to recover what was just done in your application without closing your application in the first plac If that's the case, the application is just badly coded. Memory is not special. It's just another resource. If you can't keep track of resources and release them when they're unneeded (as they would be after an error), you're doing something wrong. > http://www.gotw.ca/publications/mill16.htm http://www.gotw.ca/publications/mill16.htm That article is factually incorrect. Sutter claims that "On...Linux, memory allocation always succeeds. Full stop." That's false, as a ten-line C program that calls malloc in a loop can demonstrate. You eventually run out of address space, especially in a 32-bit process. (There's a very popular overwhelmingly 32-bit Linux distribution out there called Android. You may have heard of it.) Sutter also claims that on other operating systems, overcommit is configurable. It's in fact configurable under Linux too. Linux can run in sane, non-overcommitting mode.