Brendan (btrotter.delete@this.gmail.com) on January 19, 2020 11:25 am wrote:
> Hi,
>
> Jukka Larja (roskakori2006.delete@this.gmail.com) on January 18, 2020 9:13 pm wrote:
> > 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.
>
> Why is this hard to figure out? Don't forget that you can pre-allocate (e.g. at program
> startup/initialization, or at compile time) to avoid allocations during error handling.
>
> > > 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?
>
> Do you honestly expect me to believe that you don't think you can handle OOM (e.g. without
> allocations, etc) when it happens at the most convenient place you choose, but do think you
> can handle OOM when it happens at the least convenient place that you don't choose?
>
> > 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?
>
> Stack is pre-allocated (and without overcommit the OS guarantees that the pre-allocated stack
> is safe to use and you won't trigger OOM by using it), when you create an simple object (e.g.
> std:string, std:vector) you allocate memory (not the library that contains the objects class,
> constructor, etc) and you will (unless you intentionally broke C++) either get a reference that
> is NULL (that you must check yourself) or a "std:bad_alloc" exception (that you must catch).
>
> In theory there might be a library that allocates memory itself without giving you any hope of detecting
> that when the allocation/s fail. I have never seen this and I doubt it actually exists in practice. Anybody
> that is too incompetent to write a usable library will not write a library that anyone will use.
>
> > > 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).
>
> If you're constantly running near the limit; then the user is constantly being
> told "Sorry, you can't do that because their isn't enough memory", given that:
>
> a1) if the software happens to support a "deallocate unnecessary data to increase the chance
> of success" approach, then it will reach a point where there is nothing left for the software
> to deallocate; causing the software to fall back to some other approach.
>
> a2) if the software happens to support a "reduce quality of work to increase the chance
> of success" approach (e.g. maybe switching to lower resolution textures, etc), then
> it will reach a point where there the quality of work has reached its minimum and
> can't be reduced; causing the software to fall back to some other approach.

If I were still in games I would be doing dynamic rendering distance, so pop in happens closer in geometry heavy areas to keep a steady frame rate above 60.
Also I would be going small round worlds instead of flat so that I could have flat fields with long rendering distances. Getting sick of jagged terrains to hide poor rendering distance and hide pop in.
I bet both are common now, neither were done when I did console titles. Some titles did do pop up for distant objects, yuck.

This is not the 64k days, anyone that complains that 4 gigabytes is not enough and your app is crashing due to running out of ram is running crap software.
You can’t stream 4gb to the video card 60 times a second, games have more ram than they can use, if the programmer is using his brain.

Servers have the same issue, you are limited by your Ethernet and disk throughput and seek time, and sometimes by lack of hot data.
Too much cold data out in ram can be as useless as more disk space, if you can’t access the data fast enough then the user has moved on and your ad never rendered.

> b) the software can't be using a "wait until other work finishes (and frees memory) before
> continuing" approach (possibly as a fall-back); because if it was it can't be constantly
> running near the limit (and would be constantly waiting near the limit instead).
>
> c) the software can't be using a "report lack of memory in a manner consistent
> with all other errors, save user's data, then terminate" approach (possibly
> as a fall-back); because if it was it can only reach that limit once.
>
> d) the only other approach (that I can think of) is "cancel that one piece of work and
> inform the user, so all other pieces of work can continue" (possibly as a fall-back).
>
> Now; if the user is constantly being told "Sorry, you can't do that because their isn't enough
> memory"; then it must be because the user hasn't stopped using your software and hasn't dealt
> with the problem some other way (saving work in other apps and closing those other apps to
> increase memory available to your process without losing data, buying more RAM, ...).
>
> In other words; the only plausible scenario that could involve "constantly running near the limit" is that the
> user doesn't mind being told "Sorry, you can't do that because their isn't enough memory" constantly (possibly
> because they know they should be glad that they're not using a dodgy piece of shit that crashes instead).
>
> - Brendan
>