Brendan (btrotter.delete@this.gmail.com) on January 21, 2020 5:04 pm wrote:
>
> 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.

What's the point of cache if no-one can touch it, except to free it?

> > 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.

How?

> > 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;

That's extremely stupid engineering. Seems like you have infinite programmer resources, but lacking hardware.

> 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).

You do understand how utterly irrelevant that is for current discussion, on so many levels?

> 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).

Sounds like it would be much better to spend some money on more memory than implementing crazy OOM survival strategies.

-JLarja