Brendan (btrotter.delete@this.gmail.com) on January 18, 2020 11:40 am wrote:
> Jukka Larja (roskakori2006.delete@this.gmail.com) on January 17, 2020 9:08 pm wrote:
> > Brendan (btrotter.delete@this.gmail.com) on January 17, 2020 12:52 pm wrote:
> >
> > > The difference is when you find out that you need to deal with a low memory problem - in a well defined
> > > place (as soon as you try to allocate the memory) where it's easy to control the circumstances, or "at
> > > any time, almost anywhere" where you have to worry about the least convenient circumstances.
> >
> > So in your opinion, when ever one writes "new" or "malloc", there should be (serious) handler
> > in case of OOM? Able to release some random caches and so on, if at all applicable to that
> > particular software? And you consider that something everyone should spend time on?
>
> In my opinion; a software developer should be able to do whatever they think is sane for their software

Ok, I agree with this. What I obviously don't agree with is "sane" for most software.

> (which could include dropping cached data, and/or waiting until another thread finishes and
> releases resources,
> and/or refusing to accept additional work to ensure already accepted work succeeds,

I don't really see how one is supposed to do these things without trying to allocate any new memory, except in trivial toy examples.

> and/or reporting failure
> in a way that is consistent with the way all other problems are reported, and/or anything else); and a
> software developer should not be prevented from doing whatever they think is sane because they're forced
> to accept something that is almost never sane (either OOM killer, or SIGBUS that is unusable for most
> cases, or constant monitoring that can't solve the problem due to race conditions).

How exactly is getting an OOM on memory allocation so much better than getting it at some other random time via signal? In typical code, most allocations probably aren't done by applications own code, but some library. For example, put some std::string or std::vector to stack and they will allocate from heap too. If there's a system wide OOM going on, how can you even expect to be able to write a log message?

> Yes; but even for games, "what makes sense for the game" can depend on the game. For example, maybe for
> one game it makes sense to do an auto-save before changing to a different level/zone, then load everything
> and pre-allocate everything for the next level/zone (while managing allocation failures), then not have
> a reason to care while the player remains in that level/zone because you know everything was already allocated
> successfully; and maybe for a different game that approach can't make sense because there are no levels/zones
> (or there's multiple players or ...) and something very different is far more suitable.

Yeah, sure. If things happen to be just right, then it makes sense to do X. The game will need extra buffers to load everything the level needs from disk. They will be needed right until everything is loaded, at which point the memory consumption will be the highest (add some random variation due to multithreading and the fact that the player may decide to put the console to sleep in the middle of this).

You are also completely ignoring that memory fragmentation gets really bad really fast, if you are constantly running near the limit. If your normal mode of operation is doing something in response to allocation failures, you're screwed anyway. All that crazy amount of error handling for nothing (note that this is no longer about system wide OOM, but strictly what's happening inside a game on a console).

-JLarja