When a compression request comes in, there is a C++ process that performs the zip compression, which requires a lot of memory. Sometimes the process gets OOM killed because it runs out of memory. Also, at some point, it only throws a std::bad_alloc exception and doesn't die.
So my question is, when the server runs out of total memory, is there a difference in the conditions under which a process that requires a lot of memory will be OOM killed, or will only get a std::bad_alloc exception?
Also, why does a process that is OOM killed succeed in performing a compression operation that requires the same amount of memory when it is restarted, instead of dying?
First of all, when a system or a process runs out of memory you cannot expect any particular behavior or result. You pretty much have no guarantees, whatsoever, of any kind, as far as what the consequences are, anything beyond "stuff will stop working". With that disclaimer out of the way:
In general there are two kinds of limitations on the available memory.
An operating system may impose a fixed upper limit on the amount of memory each single process can use. For example, that limit might be 4 gigabytes and a process has reached this upper limit. Even though the entire system might have more unused memory the process has reached its limit, and its allocation request fails, resulting in a std::bad_alloc.
In the other situation this process may not have yet reached its maximum amount of memory but the entire system ran out of available memory, and that's the situation where the OOM killer finds a victim to nuke from high orbit.
Also, why does a process that is OOM killed succeed in performing a compression operation that requires the same amount of memory when it is restarted, instead of dying?
Just because last week I ran my process and it was OOMed doesn't mean that if, today, I run the same process it will also gobble up all available system memory and be OOMed again. It's a brand new day. Replace "last week" with "yesterday", or "last minute", or even "a second ago", and the same principle still holds.