Let's say a process (P1) is asking for 100 MB of memory, and the RAM looks like this:

[[50 MB free] [USED] [60 MB free] [USED]]

Since there are technically enough memory that are available (110MB free), what would happen? According to some sources I saw online, the OS will just refuse to allocate the memory, but then again isn't Linux only supposed to throw a memory error when there aren't enough memory?



2 Answers 2


If the process asks for 100MB, there has to be a contiguous 100MB free in the address space of the process (virtual memory), but those addresses can be mapped to non-contiguous pages of physical memory. The allocated addresses might not even be backed by physical pages until they are written to – Linux happily overcommits memory.

On 64 bit systems it's extremely rare that there wouldn't be enough space in the address space since there can be up to 256TB worth of virtual addresses on x86-64 hardware. This space is also not allocated in a linear manner. Due to using the ASLR security feature, parts of the virtual address space are allocated at random locations, with large parts of unmapped addresses in between.

Memory that has been dynamically allocated by the operating system to the process (e.g. with sbrk() or mmap()) has to be managed by the process itself. The application might use a garbage collector or C standard library functions like malloc() for this task. It is rather common that this allocated memory becomes fragmented over time, i.e. there are allocated addresses at which the application cannot store useful data at the moment. Whereas a garbage collection can likely move objects around in memory to reduce fragmentation, a malloc() implementation will have to request more memory from the operating system if no “hole” is large enough to satisfy an allocation request.

  • Thanks for the reply! So if I understand what you're saying, when I call malloc() it allocates a continuous block in the virtual memory (hard disk), and when needed the OS will map it to the RAM (physical memory, not necessarily continuous)? Also in the last paragraph you're talking about internal fragmentation right?
    – qwerty_99
    Jan 6, 2021 at 17:33
  • 1
    @qwerty_99 This answer talks about virtual address space, which is the address space seen from the perspective of the application process. It is not related to the OS feature of using hard disk as swapping space to provide the illusion of having more memory capacity than the actually installed physical memory size. Between virtual memory address and physical memory address, the translation is performed by a component inside the CPU called TLB (translation lookaside buffer).
    – rwong
    Jan 6, 2021 at 18:12
  • Is 265TB (or 256?) of virtual addresses the situation on Windows? On Linux it is 128TB without the P4D and 128PB with P4D. lwn.net/Articles/717293
    – joelw
    Jan 6, 2021 at 19:32
  • 1
    1. "... Linux happily overcommits memory." If you allow it to. Not that this is important here, as it need not dedicate any specific page even if overcommitting is forbidden, it just has to account for the promises given. 2. Whereas a compacting gc can likely move it around. Though the datastructures to support the gc and the necessary additional memory to make it acceptably performant are rather significant. Jan 6, 2021 at 21:01
  • @joelw The 256TB address space limit comes from hardware: of 64 bit pointers, only 48 bits are actually used. However, half of those addresses are used by the kernel, leaving 128TB for the application's address space. Of course, future hardware can support more than 48 bit addresses which the linked article seems to be about.
    – amon
    Jan 7, 2021 at 11:16

Asking about RAM is wrong, what counts is address space. If your OS is using virtual memory (which is most likely the case), then the mapping of address space to RAM is arbitrary and can change at any time, so address space counts.

The address space assigned to a process is (almost) free and can be huge; how much of it is used is what actually costs. So in your case the OS should have no problem increasing your address space by 100 MB and assigning that address space to your app. However, the OS may have a limit on how much used address space you have, and if your 100 MB exceeds that, then the request can be refused even if there is a free block of 100 MB in the processes address space.

(And you may run in trouble if you allocated 100 MB, allocated 100 MB and shrink the first block to 1KB, allocate 100 MB and shrink the second block to 1KB etc. where your "huge" address space might not be huge enough, depending on processor and OS).

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.