Hi,

Gabriele Svelto (gabriele.svelto.delete@this.gmail.com) on January 21, 2020 4:08 am wrote:
> Brendan (btrotter.delete@this.gmail.com) on January 20, 2020 10:04 am wrote:
> > You mean; sometimes a GC has to pre-allocate memory at startup
> > to ensure it has the memory it needs to make forward progress?
>
> A GC - any GC - needs a potentially unbounded amount of memory during the marking phase because it needs
> to recursively traverse all the structures present in the heap. That's pretty obvious if you think of it.

Unfortunately, no, that's not obvious if I think about it. E.g. for a simple "mark and sweep", I can't see why you can't have a "backlink" (plus "mark flag") built into each allocated object's header ("pre-allocated" as part of allocating memory for the object), so that you can traverse in one direction by searching the object for references to other objects (that you aren't already marking because they don't have their backlink field set already) and can traverse in the opposite direction by following the current object's backlink; without recursion, and without any allocations made during garbage collection.

Further, (assuming the ability to use some kind of "atomic compare and swap") I can't see why it would be hard (using the same "pre-allocated backlink" approach) to have multiple threads/CPUs doing GC at the same time.

The only thing I don't find obvious is whether "mark and sweep" can avoid stopping all other threads while "mark" happens. My intuition is telling me that it should be possible (by replacing "mark flag" with "marker version") to have no restrictions (any thread can be doing other work or doing GC at any time) with no allocations during GC; but I don't like GC and don't want to invest time into figuring out if my intuition can be trusted.

> So yes, every GC in existence potentially makes memory allocations while doing its work; the more advanced
> it is the less likely that it will be able to work w/o ever requiring additional memory (*).
>
> > Who cares? Resident set size is irrelevant when you're asking OS to commit to too much.
> > E.g. a simple "malloc(SIZE_MAX);" in a loop would be enough to trigger OOM on every 64-bit
> > OS (unless it allows infinite overcommit) with an insignificant resident set.
>
> Are you flip-flopping again? You claimed Firefox was a memory hog but the only example you picked show it definitely
> wasn't. You also picked a crash report that has a memory report attached, which sadly isn't in the public data
> because it contains PII but I can share the stats: the sum of all committed memory for that instance of Firefox
> across 5 processes was ~200 MiB of executable mappings plus ~80 MiB of shared readonly mappings (mostly files)
> and ~300 MiB of actually private unique mappings. Do you consider these numbers "too much"? BTW giving a second
> look at that crash report I believe the user might not have had a swap file at all.
>
> For those curious the user had only one open tab.

5 processes and a total of 580 MiB, for one open tab? In that case, depending on what the page was (not forgetting that some pages are like this: https://bellard.org/jslinux/vm.html?url=buildroot-x86.cfg ), I would say it's "potentially excessive". However; I still remember (e.g.) running Netscape on a machine with 64 MiB of RAM (back when > 500 MiB of disk space was rare) without a single problem, so maybe my idea of "acceptable" is lagging too far behind what other people consider "normal".

Of course I hope we all agree that "no swap at all" (for any machine that doesn't overcommit) is silly.

> > How does Rust deal with the issue? Searches lead me to believe it was a joke
> > for script kiddies that just crashes, but is "slowly evolving" in an attempt
> > to fix its problem (e.g. https://github.com/rust-lang/rust/issues/46865 ).
> >
> > Note that (as far as I know), Rust was created to avoid
> > "pointer safety issues" in C (e.g. buffer overflows,
> > etc) and memory management issues that are not related to OOM (e.g. use after free); partly by adopting the
> > stupidity of garbage collection (and then later realizing garbage collection is stupid and abandoning it).
>
> Rust ensures safety when dealing with all sorts of errors by design. Fallible allocations -
> just like any other failure in creating an object - don't return null, they return a type you're
> forced to handle separately meaning that it's impossible to propagate a null and it's impossible
> to ignore the failure. By default allocations are infallible so you have to ask for it explicitly
> when and where you think you can handle them. Just like Firefox does.

My idea of infallible is "guaranteed to always succeed", not "maybe failing but handling the failure in a generic way for you".

I'd still say that "language handling OOM in a generic way for you" is better than "OOM killer" (but worse than more specific handling).

> > Wait, maybe you're partially right.
> >
> > If FireFox creates a whole new process for every separate web page and every separate piece
> > of javascript (so that if one process crashes due to OOM it only effects that one piece
> > and not the whole app); then yes, in theory FireFox might be handling OOM properly.
> >
> > However, in that case it would basically be a malicious/trojan fork bomb designed to trick the OS into
> > committing everything it can, and causing everything to fail. Every time it creates a new process it asks
> > the OS to commit to providing memory for a new copy of the entire program's modifiable pages until the
> > system as a whole starves. Of course it would also make it difficult for one piece (in one process) to
> > ask the rest of the pieces (in other processes) to free up memory used for caches, etc (to avoid failure);
> > so even in the "fork bomb" case it's likely that it's not handling OOM as well as it could.
>
> Since you're clearly well versed in this topic you're welcome to help.
>
> > No; that's just the bare minimum handling possible, which
> > can only be acceptable if there's no better way it
> > could've been handled. For something like GCC (where it can't continue without the memory, doesn't have any
> > cached data it can discard, and can't sacrifice some work to
> > allow other work to succeed) the only other alternative
> > is to wait in the hope other processes release memory; but
> > that can't work in some very common use cases (e.g.
> > "make -j" leading to multiple separate copies of GCC all waiting for each other to finish).
>
> Can you point me to an actual example of a codebase handling OOMs the way you describe?
> Just one would suffice because until now you waved your hands a lot but failed
> to provide a single practical example across more than a dozen posts.

I didn't describe "a way", I described multiple potential methods of handling OOM (where which is best depends on the specific case).

I won't waste my time finding more examples of each possible way of handling OOM just so you can say "Oh, it only uses method A and not method B" again; especially when my main point is that overcommit has led to software not doing these things; and especially after you spent days trying to convince me that FireFox does do (some of) these things (and is an example that you're asking for).

Can you point to any actual example of a codebase that does not use any of the multiple potential methods I've described, that is "not shit" (not improvable) and is not intended for a "no multi-tasking, all computers identical" environment?

> > Previously you said the crash logs include crashes from Linux and
> > MacOS (and that crashes on Windows are 20 times as likely).
> >
> > Note that my current suspicion is that FireFox partly does things that are stupid (expects OS to commit
> > to far too much, causing it to crash more on Windows because Windows is better at defending itself
>
> ROFLMAO.

What, exactly, do you think is funny about (e.g.) preventing rogue processes from tricking the OS into killing system services/daemons or the entire GUI? Linux (kernel, and distros) have spent about 20 years trying to work around those problems.

- Brendan