To my surprise, I recently found out that Windows would fail a large memory allocation even if little of said memory is to actually be used, e.g. even if you don't want the swap, you better not disable it. http://brandonlive.com/2010/02/21/measuring-memory-usage-in-windows-7/ (Basically, in Windows 7, Windows Task Manager, Performance, System, Commit, -- the sum of the physical memory plus the swap file is depicted, and a mere allocation of 2GB will immediately grow the figure by 2GB, unless such growth is restricted (e.g. if the page file is disabled), then the whole allocation would fail.)

I recall that it's also the case with OpenVZ virtualisation, which behaves the same way, thus being incompatible with Java, for example. However, I never really heard of anything like that in regards to the virtual memory of other operating systems, like FreeBSD, OpenBSD or non-OpenVZ Linux (which doesn't necessarily mean that they don't behave the same).

What's the history behind such behaviour, and how the popular systems generally behave in such situation? I mean, isn't virtual memory supposed to be unlimited on any system?

  • 2
    $\begingroup$ Fail-fast has significant advantages. (By the way, zero pages would fail on write not read.) For a client system, allowing the user to select the process to kill may be preferred over invoking an out-of-memory killer heuristic. For a system that is not directly monitored in this way, automation might be preferred. I suspect the Unix philosophy may be involved (let the user do stupid things so that the user can do clever things and simple things simply). Just speculation, not an answer. $\endgroup$ – Paul A. Clayton May 22 '15 at 19:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.