6 ms·

In practice i haven't seen any application to gracefully handle out of memory situations. Even back in Windows 3.x days when running out of memory was common, m

by Crinus 7y ago

In practice i haven't seen any application to gracefully handle out of memory situations. Even back in Windows 3.x days when running out of memory was common, most applications simply hanged or crashed (which also took the entire GUI with them) and those that didn't often had a "no memory, kthxbye" dialog that shut down the application. A very few rare cases would try to display some "sorry, no memory, close some programs and try again" dialog but even those were hit and miss, depending on the situation. Once 32bit hardware-based virtual memory entered the picture, every single application would just assume you have endless RAM - memory checks are reserved for "common cases" like trying to create a 100000x100000 image in a (32bit) image editor. The reason for all that is simple: out of memory situations are stupidly and increasingly rare and in most cases where they can happen there isn't much you can do (e.g. what would you do if you run out of memory while making the fourth button in a toolbar?) and really in the 99% of the cases there might only be five people in the entire universe that will encounter such a case (two of them will tweet about it though and amass a lot of "lol, those garbage developers" retweets) so littering your codebase to keep those five people (and their Twitter followers) happy is not worth the effort. I mean, are you really going to put a "run out of memory" check after every toolbar button allocation? And what are you going to do if that fails? What can you do? AFAIK some modern languages nowadays even assume memory allocations wont fail (and if they do they just terminate).

chrisseaton 7y ago
> what would you do if you run out of memory while making the fourth button in a toolbar? Rollback what I’d created so far, evict caches, ask malloc to trim, try again, if that failed roll back again and ask the user to reduce the volume of application data open by closing views or documents or whatever before they try again. But yeah it’s a lot of engineering.
- gmueckl 7y ago
  So you meant to say: ignore the possibility of this happening because it is extremely unlikely, too complex to handle and your time is better spent fixing much ore serious bugs that the users report. Silly engineering like what you suggest is a waste of time. Non-critical applications that are allowed to crash (every normal desktop app) would end up overengineered and unmaintainable. Embedded systems that must give guarantees about their reliability simplify system design drastically. One of the things going out the window first is dynamic memory allocation. It has too many failure modes.
- Crinus 7y ago
  > ask the user You just failed to create a toolbar button, how are you going to ask a user do something if you already failed to create a tiny UI element?
  - hyperman1 7y ago
    I guess you pre-allocate these UI elements when you start your application.
    - Crinus 7y ago
      What if malloc fails at that point because some other application (we're in a preemptive multitasking OS) decided to gobble up all RAM?
      - fwip 7y ago
        If your application fails at start-up, you don't need to worry about saving state and graceful failure.
AnonymousPlanet 7y ago
Keep in mind that Windows 3.x wasn't really the pinnacle of computing in its days. PCs were relatively irrelevant compared to the systems everyone apart from a mom and pop shop ran their business on. So the typical behavior you saw was a combined effect of physical constraints and lack of skill or care.
- Crinus 7y ago
  No it wasn't which is exactly why i brought it up (well that, and it was the most popular - despite its shortcomings).
joosters 7y ago
Plus, you can do all the graceful malloc() failure handling that you want, but if the kernel hasn't got overcommit disabled, then your program can still exit uncleanly when you later on try to use some malloc()d memory that was overcomitted. Exiting cleanly would mean trapping SIGBUS/SIGSEGV (can't remember which one is invoked) and being able to roll-back from just about any point in your code or libraries) You need to ensure overcommit is disabled, but because that's a system-wide setting, your program can't easily force that on.
tokenrove 7y ago
https://www.sqlite.org/malloc.html https://www.sqlite.org/malloc.html is a welcome contrast to the typical behavior you're describing, but I agree that such measures are rare. (and, not an application: though it provides the mechanisms for applications to follow its lead.)
asveikau 7y ago
> In practice i haven't seen any application to gracefully handle out of memory situations I have seen code hit an allocation failure, bubble the error up the stack, which causes various pieces of code along the stack to free their heap allocations, all the while the process is able to log what is going and keep running. I have even seen this happen when the allocation that failed was tiny, less than 100 bytes.
TheCondor 7y ago
What is your definition of graceful in this case? Presumably there was a “business need” for the allocation and the software isn’t just allocating for fun. An allocation failure is a hard fault, it’s not possible to honor the business need so something expected to happen cannot happen. The program could segfault when the null pointer returned is written to, that is kind of crappy. It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” Or it could be a completely temporal thing, maybe you flush some caches or something to free up some memory and reschedule the work. I don’t know, maybe this is old school, but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job and two it is a very very slippery slope when you start ignoring those errors as a matter of practice
- Crinus 7y ago
  > It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job This is a reason to put checks in every toolbar allocation, but on the other hand there is also a reason to not do that: you are trying to catch a case that will only happen at a 0.00001% of the time yet to do that you are making the codebase more complex which will affect working with it 100% of the time. Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Even then when it comes to high risk programs relying on the programmer doing things right outside the core functionality is probably (i haven't worked on such projects myself so i'm guessing here) not a good idea and instead you should compartmentalize (e.g. the core functionality is running as a separate process from the UI and if the UI crashes, a watchdog restarts the UI process). But that is my guess here, i mainly have common end user/consumer applications in mind.
  - 95014_refugee 7y ago

by Crinus 7y ago

chrisseaton 7y ago

> what would you do if you run out of memory while making the fourth button in a toolbar? Rollback what I’d created so far, evict caches, ask malloc to trim, try again, if that failed roll back again and ask the user to reduce the volume of application data open by closing views or documents or whatever before they try again. But yeah it’s a lot of engineering.

gmueckl 7y ago
So you meant to say: ignore the possibility of this happening because it is extremely unlikely, too complex to handle and your time is better spent fixing much ore serious bugs that the users report. Silly engineering like what you suggest is a waste of time. Non-critical applications that are allowed to crash (every normal desktop app) would end up overengineered and unmaintainable. Embedded systems that must give guarantees about their reliability simplify system design drastically. One of the things going out the window first is dynamic memory allocation. It has too many failure modes.
Crinus 7y ago
> ask the user You just failed to create a toolbar button, how are you going to ask a user do something if you already failed to create a tiny UI element?
- hyperman1 7y ago
  I guess you pre-allocate these UI elements when you start your application.
  - Crinus 7y ago
    What if malloc fails at that point because some other application (we're in a preemptive multitasking OS) decided to gobble up all RAM?
    - fwip 7y ago
      If your application fails at start-up, you don't need to worry about saving state and graceful failure.

AnonymousPlanet 7y ago

Keep in mind that Windows 3.x wasn't really the pinnacle of computing in its days. PCs were relatively irrelevant compared to the systems everyone apart from a mom and pop shop ran their business on. So the typical behavior you saw was a combined effect of physical constraints and lack of skill or care.

Crinus 7y ago
No it wasn't which is exactly why i brought it up (well that, and it was the most popular - despite its shortcomings).

joosters 7y ago

Plus, you can do all the graceful malloc() failure handling that you want, but if the kernel hasn't got overcommit disabled, then your program can still exit uncleanly when you later on try to use some malloc()d memory that was overcomitted. Exiting cleanly would mean trapping SIGBUS/SIGSEGV (can't remember which one is invoked) and being able to roll-back from just about any point in your code or libraries) You need to ensure overcommit is disabled, but because that's a system-wide setting, your program can't easily force that on.

tokenrove 7y ago

https://www.sqlite.org/malloc.html https://www.sqlite.org/malloc.html is a welcome contrast to the typical behavior you're describing, but I agree that such measures are rare. (and, not an application: though it provides the mechanisms for applications to follow its lead.)

asveikau 7y ago

> In practice i haven't seen any application to gracefully handle out of memory situations I have seen code hit an allocation failure, bubble the error up the stack, which causes various pieces of code along the stack to free their heap allocations, all the while the process is able to log what is going and keep running. I have even seen this happen when the allocation that failed was tiny, less than 100 bytes.

TheCondor 7y ago

What is your definition of graceful in this case? Presumably there was a “business need” for the allocation and the software isn’t just allocating for fun. An allocation failure is a hard fault, it’s not possible to honor the business need so something expected to happen cannot happen. The program could segfault when the null pointer returned is written to, that is kind of crappy. It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” Or it could be a completely temporal thing, maybe you flush some caches or something to free up some memory and reschedule the work. I don’t know, maybe this is old school, but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job and two it is a very very slippery slope when you start ignoring those errors as a matter of practice

Crinus 7y ago
> It could report the error “hey we are out of memory and couldn’t do xyz” or better “hey we are out of memory and couldn’t do xyz, this is probably because of abc, maybe you can adjust the tuning.” What if you cannot do that report because the reporting itself needs memory that can fail? > but yes you should put a check on every toolbar allocation for two reason: one you can gracefully report why your app isn’t doing it’s job This is a reason to put checks in every toolbar allocation, but on the other hand there is also a reason to not do that: you are trying to catch a case that will only happen at a 0.00001% of the time yet to do that you are making the codebase more complex which will affect working with it 100% of the time. Unless you are working in something like a medical or nuclear device, it is not worth to bother with such things. Even then when it comes to high risk programs relying on the programmer doing things right outside the core functionality is probably (i haven't worked on such projects myself so i'm guessing here) not a good idea and instead you should compartmentalize (e.g. the core functionality is running as a separate process from the UI and if the UI crashes, a watchdog restarts the UI process). But that is my guess here, i mainly have common end user/consumer applications in mind.
- 95014_refugee 7y ago