4 ms·

There are lots of non-fatal ways to handle an out of memory condition (including doing your own paging) depending on the use-case of the allocation. Programmers

There are lots of non-fatal ways to handle an out of memory condition (including doing your own paging) depending on the use-case of the allocation. Programmers suffer from learned helplessness because they're writing for systems that lie to them about memory and languages that make handling errors a pain.

tinus_hn 4y ago
That sounds obvious until you realize that you can’t get away with just fixing the obvious parts of allocating large optional caches, you have to defend for every single allocation you do to fail. In every library you use, for every string you copy, for every structure you create. That’s a lot harder than handwaving about how someone else might be able to fix some cases.
- AnIdiotOnTheNet 4y ago
  Yes, and? The difficulty of this is overstated. Except maybe that library thing, but my general guiding principle is to use as few dependencies as possible already anyway so that mitigates it somewhat. If there are some situations where there is no logical course of action? Then yeah, crash I guess. Assuming your software isn't responsible for people's lives. It's still better than the OS randomly killing you because some other program fucked up. I mean this is just crazy. The OS lies to you about memory, you ignore it anyway since it always lies to you, and then we randomly kill programs when we're out of memory. This is not a reasonable way to do things. The problem, as I see it, is that by now programmers are so used to not paying attention to memory (or any other resource in most cases) that there's a ton of inertia behind the "nothing can be done" sentiment.
  - tinus_hn 4y ago
    I suggest you pick up a project and show us how easily this can be done.
    - AnIdiotOnTheNet 4y ago
      Leave that aside for a sec. Are you honestly saying that because it isn't easy to do this, the best course of action is to make it impossible by lying to the program?
      - tinus_hn 4y ago
        If it bothers you, you can just turn off overcommit. It’s not hard: $ sysctl vm.overcommit_memory=2 # policy number 2 $ sysctl vm.overcommit_ratio=0 # ratio = 0% So here’s your golden opportunity to show us how easy it is to program against that! I didn’t claim that it is not easy. I claimed that it is practically impossible. You claimed it was easy. So please, prove me wrong and just show us how easy it is.
        AnIdiotOnTheNet 4y ago
        That's for the entire system though. If this behavior is default because programs suck at dealing with memory then that will definitely cause problems, right? That's why we're in this shitpickle to begin with. Obvious solution is obvious: opt in to no-overcommit behavior on a per-program basis and exempt programs that opt-in from being OOM killed. > I claimed that it is practically impossible. Suddenly it makes sense why modern software is such unreliable slow garbage. You don't by chance work for Microsoft on the Windows Terminal team do you? If this is so impossible, why would so many other OSs actually correctly not-lie to the program about memory allocation failure? > So here’s your golden opportunity to show us how easy it is to program against that! Alright, what would you like me to program for you for free and how long are you going to give me[0], because the vast majority of code I write doesn't even have to allocate at all. Even the stuff that does just does the obvious thing when it can't allocate what it needs: tell the user it can't allocate what it needs and exit as gracefully as possible. Even that is impossible on an OS that fucking lies to you. [0] No, I'm not going to actually do it. This whole tactic is predicated on the idea that it is more work than someone is willing to go through to prove a point on the internet, you know that, that's why you went there.
        4y ago

tinus_hn 4y ago

That sounds obvious until you realize that you can’t get away with just fixing the obvious parts of allocating large optional caches, you have to defend for every single allocation you do to fail. In every library you use, for every string you copy, for every structure you create. That’s a lot harder than handwaving about how someone else might be able to fix some cases.

AnIdiotOnTheNet 4y ago
Yes, and? The difficulty of this is overstated. Except maybe that library thing, but my general guiding principle is to use as few dependencies as possible already anyway so that mitigates it somewhat. If there are some situations where there is no logical course of action? Then yeah, crash I guess. Assuming your software isn't responsible for people's lives. It's still better than the OS randomly killing you because some other program fucked up. I mean this is just crazy. The OS lies to you about memory, you ignore it anyway since it always lies to you, and then we randomly kill programs when we're out of memory. This is not a reasonable way to do things. The problem, as I see it, is that by now programmers are so used to not paying attention to memory (or any other resource in most cases) that there's a ton of inertia behind the "nothing can be done" sentiment.
- tinus_hn 4y ago
  I suggest you pick up a project and show us how easily this can be done.
  - AnIdiotOnTheNet 4y ago
    Leave that aside for a sec. Are you honestly saying that because it isn't easy to do this, the best course of action is to make it impossible by lying to the program?
    - tinus_hn 4y ago
      If it bothers you, you can just turn off overcommit. It’s not hard: $ sysctl vm.overcommit_memory=2 # policy number 2 $ sysctl vm.overcommit_ratio=0 # ratio = 0% So here’s your golden opportunity to show us how easy it is to program against that! I didn’t claim that it is not easy. I claimed that it is practically impossible. You claimed it was easy. So please, prove me wrong and just show us how easy it is.
      - AnIdiotOnTheNet 4y ago
        That's for the entire system though. If this behavior is default because programs suck at dealing with memory then that will definitely cause problems, right? That's why we're in this shitpickle to begin with. Obvious solution is obvious: opt in to no-overcommit behavior on a per-program basis and exempt programs that opt-in from being OOM killed. > I claimed that it is practically impossible. Suddenly it makes sense why modern software is such unreliable slow garbage. You don't by chance work for Microsoft on the Windows Terminal team do you? If this is so impossible, why would so many other OSs actually correctly not-lie to the program about memory allocation failure? > So here’s your golden opportunity to show us how easy it is to program against that! Alright, what would you like me to program for you for free and how long are you going to give me[0], because the vast majority of code I write doesn't even have to allocate at all. Even the stuff that does just does the obvious thing when it can't allocate what it needs: tell the user it can't allocate what it needs and exit as gracefully as possible. Even that is impossible on an OS that fucking lies to you. [0] No, I'm not going to actually do it. This whole tactic is predicated on the idea that it is more work than someone is willing to go through to prove a point on the internet, you know that, that's why you went there.
        4y ago