Hi,

Jukka Larja (roskakori2006.delete@this.gmail.com) on January 21, 2020 6:01 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 20, 2020 11:43 am wrote:
> > Jukka Larja (roskakori2006.delete@this.gmail.com) on January 20, 2020 4:54 am wrote:
> >
> > > With oracle telling us that the end is near, these are practical approaches (not on consoles
> > > in my opinion, but on general purpose system). Unfortunately we don't have oracle.
> >
> > Would you like me to write an oracle that "predicts" that a previous call to malloc()
> > returned NULL, that a previous call to "mmap()" returned -1 (with errno set to ENOMEM),
> > or that a previous attempt to create a new object resulted in "std::bad_alloc"?
> >
> > It seems to me that for all cases the oracle can be a macro that does literally nothing (or maybe
> > just a line of white space inside a "try to allocate and free cache if you need to" wrapper).
>
> This is pointless. You are talking about some toy programs where freeing (some mysterious) cache can
> be done at any point and no one will care.

No, the same approach can/will work for anything that has any kind of cache, regardless of the complexity.

> Any such memory in our game engine is such that it can't
> be freed before the operation using it is done.

If none of the memory can be freed because it's being used then your game engine has no cache/s.

> That may be OK, if that operation itself faces OOM
> and can abort, but that's unlikely. Much more likely the OOM will happen in some other thread. And
> when you get one, you'll probably get several more soon. That's why the oracle is needed.

You don't need an oracle to do this. E.g. you can inform other threads that they need to reduce the amount of memory they're currently using (and wait until the other threads inform you that they have); without any attempt to predict the future.

> And you are running your toy programs on some mysterious system that seems to be constantly running out
> of memory. I mean, why else would you spend so much time trying to handle OOMs without crashing?

I (try to) handle every possible problem that might happen, regardless of how likely/unlikely it is; primarily because (for my software) the end user's data is not worthless. In other words, I need to care because my software is not "literally a toy, for entertainment purposes only" (unlike games).

Note: For previous work (operating systems) I don't even assume hardware works (e.g. I've probably spent 6 months just researching/prototyping "software/kernel based RAM fault detection and correction" for systems that don't have ECC).

> If you want to improve user experience of OOM crash just autosave every
> now and then. It will help for every other kind of crash too.

That's a good idea (for some cases); but prevention is always better than treating symptoms.

The software I'm currently working on is half "collaborate real-time editor" (see https://en.wikipedia.org/wiki/Collaborative_real-time_editor ). Basically; users log in to the server, select a project/s they want to work on, then edit the project/s (while many other users may also be editing the same project/s). If the server crashes all users get annoyed (then probably try to reconnect before server comes back online, then realize they have no idea how long server will be down for and probably take a coffee break); then (after the server comes back online) all users log back in and have to try to figure out how much of their work was lost from which file/s, then users have to redo the work that was lost. If you assume (as a crude estimate for design goal purposes) there will be 100 users and the disruption costs each user an average of 20 minutes (e.g. auto-save every modified file every 5 minutes); then it'd add up to about 33 hours of lost productivity, and you might be able to say it'll costs about $1000 each time the server crashes (despite auto-saves).

- Brendan