Brendan (btrotter.delete@this.gmail.com) on January 16, 2020 6:16 am wrote:
> Oh, that sounds easy. [...]

You still haven't shown me a codebase gracefully handling all allocation failures. Maybe it's not as easy as you claim.

> You control which dependencies you depend on; and if you choose to depend on a hideous design failure
> (e.g. that has functions that need to allocate memory but don't tell you they failed and force you
> to assume something succeeded when it didn't) then that is your fault for making bad choices.

Do you control Windows system libraries? Are they bug-free and always infallibly return error conditions? What about code coming from graphics drivers which you will encounter if you need to do anything which involves graphics?

> Um, what?
>
> If there's a library function that always returns "success" (but the docs don't say that success is guaranteed
> in all future versions of the library) and another programmer calls it without checking the return value
> (that is always "success"), then I tell the other programmer they're incompetent and refuse to work with
> that programmer ever again (because a future version of that library might return something else).

So you're basically working alone or do you really believe that no errors ever slip through? We've designed Rust to make error handling both mandatory and easy precisely because forgetting error handling - or getting it wrong - happens all the time in practice.

> Have you ever tried to use signals before? You get a signal while your in the middle of
> who-knows-what; then what? Cause a deadlock while trying to acquire a lock you need to free
> memory you were using to cache something? Inform a thread that it needs to terminate to
> save other threads and wait for it to also receive SIGBUS and cause more problems?

Yes, in fact I've written complex code running in signal-handlers across three platforms (Linux, macOS and Windows). We use those to gather data about crashed processes for reporting and recover. In fact we just landed a patch that will make Firefox front-end capable of automatically restoring processes that crashed due to an OOM.

> Yes; GCC was just the easiest example of "bare minimum handling of allocation failures".

No it doesn't. It just aborts instead of returning NULL so all the code in it can pretend that allocations never fail. It's doing the opposite of what you claim.

> Heh, no. What you have is proof that a well known resource hog is actually a resource hog. Look at the crash
> reports - they're all saying "90%+ of system memory used, available page file size reduced to zero".

Only 35% of those crash reports have >= 90% system memory usage. Not all of them. Over 10% have less than 50% memory usage. You clearly didn't look at the data. It's also disingenuous to look at system memory usage without correlating it to the total amount of physical memory. A quick check would have revealed that machines in the >90% bracket are made up mostly of users with 2-, 3- or 4GiB of RAM.

> Tell me,
> how do you think Windows is supposed to hibernate properly when you've gobbled 100% of RAM and 100% of disk?
> The only problem I see here is that Windows isn't using per-process quotas to stop your memory leak sooner.

How do you explain that OOM crashes are over 20 times more likely on Windows than on Linux and macOS? Isn't Firefox a memory hog on Linux and macOS too?

> As far as I can tell (I'm "not great" at C++ and only looked at small scraps of a large project) the
> reason they're crashes (and not "reductions in amount of data cached for later" or "dialog boxes telling
> user one of their tabs needs to be closed" or anything else that could be considered acceptable) is that
> FireFox's screws up "new()" so that (despite the "noexcept(false)") it fails to throw an exception when
> there's OOM (preventing the caller, who has the knowledge needed to figure out the best way to handle
> OOM and/or can send the error up the call stack to whatever is most suited to handling the OOM, from
> being involved) and just ends up at an incredibly stupid "We might proceed to a stage 2 in which an attempt
> is made to reclaim memory" comment in unfinished code that will never attempt to reclaim memory (because
> actually trying to reclaim memory would be horrifically complex when you don't have any of the caller's
> knowledge about the current context - e.g. which mutexes are currently held, etc).

It's quite the opposite. Firefox tries very hard to free memory when it's approaching an OOM. I wrote the code that detects and responds to low memory conditions on Windows. It runs garbage collections, prunes caches, flushes buffers to save memory. I even wrote code that shuts down unneeded processes in response to that, to shrink memory usage even further. Heck, I wrote code that forces our custom allocator to aggressively give back pages it doesn't need to the operating system.

Now tell me, do the applications you wrote go to these lengths to actually detect and prevent OOMs? Because if they don't you're being comically wrong about "Firefox screwing up new()". And it's even sillier considering that we have explicitly fallible allocators so that we can recover gracefully from failures in places where it's possible.