In addition to this guy having a total misunderstanding of how this worked and why it eventually failed ("control structures"?!") the article glosses over how this behavior relates to configuration options such as vm.overcommit... it doesn't even use the correct term (overcommit), so readers don't manage to even leave with the ability to rapidly learn more about the subject.
Yet, I have now been tricked into seeing it twice, as in addition to being on the HN home page for over 6 hours (with not that many upvotes, but still way too many) it was renamed by a moderator from the original title it was posted with ("Malloc never fails", weirdly in the opposite direction of the policy of "use the original title" that is normally cited for legitimizing renames) so you couldn't recognize "oh, this is that wrong article from earlier".
Worse, a somewhat informative comment on this site from the user "khm", one that links to a better article that discusses these issues with the right terminology an in context with the OOM killer, is marked [dead], caught by some spam filter or maybe even dowvoted/flagged to death by readers.
> We just need to be careful because malloc returning successfully does not always mean that we can use the requested memory.
this is not really true and it's dangerous to think this way (IMO).
one of the awesome things about virtual memory is you can "use" more memory than you actually have. if you only have 4GB of physical pages on your system and you allocate 18GB of virtual memory, things will be fine until you write to more pages than you have.
at this point, things are still fine! the memory manager will pick some pages (usually ones that haven't been accessed in a while) and page them out to a paging file. this behavior is transparent to your application. when your application tries to access those pages, the memory manager will bring those pages back in. if it can't bring the pages back in because all the pages are taken, it will choose some pages to put back into the page file. and so on ...
"so what happens when the page file is full?" well, modern operating systems have a page file that grows. so really, "what happens when the page file is uncomfortably large" is the question, and the answer there is the kernel will start killing tasks, and the first on the chopping block will probably be yours.
some platforms allow you to register for notification from the memory manager that there is a lot of pressure for physical pages or virtual addresses. the problem with trying to gain awareness like this is that the pressure on memory is generally totally outside your control. if the memory manager tells your app 'hey, free any memory you're not using' you are going to say 'oh yeah right i just had these hundreds of megabytes just sitting around but now that you mention it i probably should release them'. uh huh.
imo short takeaway:
1. check if malloc is null because the behavior of the allocator is platform dependent.
2. if you get a non-null pointer from malloc, treat it is valid. there is nothing else you can do. perhaps touching it will make the kernel kill your task perhaps not! it could be because your app is using too much memory. it could be because the app next door is using too much memory! you can't know.
3. you should take an operating systems class from a university if you want to really explore this topic in depth
>> and the first on the chopping block will probably be yours.
Unfortunately this often won't be the case. The algorithm used for selection in the oom killer will try to preserve processes which have accumulated higher CPU time - on a typical server, the most active process will often be the one consuming all the memory.
This can lead to a painful situation where critical processes like sshd, or your shell, are killed off to allow more space for the runaway app. Quickly leading to a hard reset being the only recovery option.
With an application using garbage collection it's quite easy to have hundreds of megabytes just sitting around, so I think it could be a good idea in some cases.
aha! true, yes. I hadn't considered that case. then it would make sense. I suppose another case would be if you were maintaining some kind of data cache that could either be discarded or flushed to disk. so maybe these mechanisms are more useful than I thought.
Even after having the occasional run-in with the OOM killer and having to drive into work at 3am because sshd was among the casualties, I can't see thwarting the OS's virtual memory system like this.
Besides, if you're really that worried about uptime that falling victim to the OOM killer is an unacceptable risk, you should be preparing for surprise hardware failure too, which in my experience is much more likely to happen anyway and can be just as fatal to your "invincible" process.
Makes me respect the early engineers and programmers who have put in great thought in building these blocks. Seriously, reading through all this in HTML5, Android, iOS world of today with IDE, code samples, every book and whole communities to help you, make me respect early programmers so much. They were the real risk takers to venture into something entirely unknown and created a whole new discipline which is empowering every existent discipline and creating many more.
This guy is wrong, for the record. The default behavior of malloc on linux involves kernel magic to decide whether to allocate the memory. Since he wasn't actually writing any data to any of his ram, it didn't fail until he ran out of address space. If he'd actually used the memory, it would have failed sooner.
The other, bigger problem is his assumption that all linux installations work like this. Frequently vm.overcommit_memory is set to disable malloc calls for more than the available amount of memory, which means the oom-killer never gets inolved. He's making a ton of dangerous assumptions based on tooling around with code instead of reading the documentation on the matter (i.e. malloc(3)).
I love articles like this. I always learn something new. I must admit that I did think that malloc would use VM if necessary hence giving a potentially "unlimited" address space, but I guess it is nice to have that cemented rather than theorized.
Can we ever really count on memory being allocated to RAM? I think not (it's against the kernel/user buffer right?), but it's good to know these things.
Of course: I attempt to always be in a learning phase so if anyone can expand (or elaborate) then I'd appreciate it :)
I must admit that I did think that malloc would use VM if necessary hence giving a potentially "unlimited" address space
There's no distinction between "VM" and non "VM" as far as malloc is concerned. From the perspective of the process, it's one big, flat address space. It's always "virtual", because the values of the pointers do not necessarily equal the physical layout of the memory that is directly backed by RAM.
Most systems have calls that tell the OS "this page must stay in physical memory". On Unix-like systems, "man mlock" probably tells you more. On Windows, I think the equivalent is called VirtualLock.
Meta: The article itself is wrong as it was pointed out here. However, I learned a lot from the discussion around it. Should I upvote the submission or not?
Readit News
Yet, I have now been tricked into seeing it twice, as in addition to being on the HN home page for over 6 hours (with not that many upvotes, but still way too many) it was renamed by a moderator from the original title it was posted with ("Malloc never fails", weirdly in the opposite direction of the policy of "use the original title" that is normally cited for legitimizing renames) so you couldn't recognize "oh, this is that wrong article from earlier".
Worse, a somewhat informative comment on this site from the user "khm", one that links to a better article that discusses these issues with the right terminology an in context with the OOM killer, is marked [dead], caught by some spam filter or maybe even dowvoted/flagged to death by readers.
Frowny pants.
this is not really true and it's dangerous to think this way (IMO).
one of the awesome things about virtual memory is you can "use" more memory than you actually have. if you only have 4GB of physical pages on your system and you allocate 18GB of virtual memory, things will be fine until you write to more pages than you have.
at this point, things are still fine! the memory manager will pick some pages (usually ones that haven't been accessed in a while) and page them out to a paging file. this behavior is transparent to your application. when your application tries to access those pages, the memory manager will bring those pages back in. if it can't bring the pages back in because all the pages are taken, it will choose some pages to put back into the page file. and so on ...
"so what happens when the page file is full?" well, modern operating systems have a page file that grows. so really, "what happens when the page file is uncomfortably large" is the question, and the answer there is the kernel will start killing tasks, and the first on the chopping block will probably be yours.
some platforms allow you to register for notification from the memory manager that there is a lot of pressure for physical pages or virtual addresses. the problem with trying to gain awareness like this is that the pressure on memory is generally totally outside your control. if the memory manager tells your app 'hey, free any memory you're not using' you are going to say 'oh yeah right i just had these hundreds of megabytes just sitting around but now that you mention it i probably should release them'. uh huh.
imo short takeaway:
1. check if malloc is null because the behavior of the allocator is platform dependent.
2. if you get a non-null pointer from malloc, treat it is valid. there is nothing else you can do. perhaps touching it will make the kernel kill your task perhaps not! it could be because your app is using too much memory. it could be because the app next door is using too much memory! you can't know.
3. you should take an operating systems class from a university if you want to really explore this topic in depth
Unfortunately this often won't be the case. The algorithm used for selection in the oom killer will try to preserve processes which have accumulated higher CPU time - on a typical server, the most active process will often be the one consuming all the memory.
This can lead to a painful situation where critical processes like sshd, or your shell, are killed off to allow more space for the runaway app. Quickly leading to a hard reset being the only recovery option.
Even after having the occasional run-in with the OOM killer and having to drive into work at 3am because sshd was among the casualties, I can't see thwarting the OS's virtual memory system like this.
Besides, if you're really that worried about uptime that falling victim to the OOM killer is an unacceptable risk, you should be preparing for surprise hardware failure too, which in my experience is much more likely to happen anyway and can be just as fatal to your "invincible" process.
The other, bigger problem is his assumption that all linux installations work like this. Frequently vm.overcommit_memory is set to disable malloc calls for more than the available amount of memory, which means the oom-killer never gets inolved. He's making a ton of dangerous assumptions based on tooling around with code instead of reading the documentation on the matter (i.e. malloc(3)).
malloc can fail, and you should deal with it well: http://ewontfix.com/3/
Of course: I attempt to always be in a learning phase so if anyone can expand (or elaborate) then I'd appreciate it :)
There's no distinction between "VM" and non "VM" as far as malloc is concerned. From the perspective of the process, it's one big, flat address space. It's always "virtual", because the values of the pointers do not necessarily equal the physical layout of the memory that is directly backed by RAM.