3 ms·

> 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

by munin 14y ago

> 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

joshhart 14y ago
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.
- cbhl 14y ago
  Perhaps, but an application using garbage collection will likely have malloc abstracted away from the developer.
  - anders0 14y ago
    But couldn't the language's runtime (or the GC library, or whatever) register for these notifications?
    - cbhl 14y ago
      Yes, but my impression is that the set of conditions where this helps (you have memory pressure AND the runtime has lots of memory it can free up) is rather rare. If you have memory pressure, that's usually the same time that the runtime is actually trying to make use of lots of memory. IIRC, Android provides something along these lines (as does Windows Phone 7.1), and when you get under memory pressure (common on Honeycomb-based tablets) you end up with thousands of these notifications, each freeing up 1KB or 2KB when you really need to free up tens of megabytes (which you can only do by serializing and terminating an application).
- munin 14y ago
  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.
LnxPrgr3 14y ago
I've seen people go to extreme lengths to avoid being a victim of overcommitted memory: http://www.baus.net/memory-management http://www.baus.net/memory-management 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.
3amOpsGuy 14y ago
>> 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.

by munin 14y ago

joshhart 14y ago

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.

cbhl 14y ago
Perhaps, but an application using garbage collection will likely have malloc abstracted away from the developer.
- anders0 14y ago
  But couldn't the language's runtime (or the GC library, or whatever) register for these notifications?
  - cbhl 14y ago
    Yes, but my impression is that the set of conditions where this helps (you have memory pressure AND the runtime has lots of memory it can free up) is rather rare. If you have memory pressure, that's usually the same time that the runtime is actually trying to make use of lots of memory. IIRC, Android provides something along these lines (as does Windows Phone 7.1), and when you get under memory pressure (common on Honeycomb-based tablets) you end up with thousands of these notifications, each freeing up 1KB or 2KB when you really need to free up tens of megabytes (which you can only do by serializing and terminating an application).
munin 14y ago
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.

LnxPrgr3 14y ago

I've seen people go to extreme lengths to avoid being a victim of overcommitted memory: http://www.baus.net/memory-management http://www.baus.net/memory-management 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.

3amOpsGuy 14y ago

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