What does it mean that "the memory requested by JVM from the OS has to be contiguous"?

Viewed 135

I've seen many people on the web claiming that "the JVM requests a contiguous unfragmented block of memory from the OS when it starts". What I can't understand is how this correlates with the notion of virtual memory.

OS might swap out any process's memory pages to disk, then load them again into RAM - chances are they will be loaded into different locations, so physical memory used by the process will no longer be contiguous.

As for the process's virtual memory - that will always be "contiguous" from the process's point of view, as each process has its own address space.

Thus, what I'd like to understand is:

  • Is the statement that memory allocated by OS to a JVM has to be
    contiguous really true?
  • If so, how does OS ensure memory stays contiguous considering it might be swapped out to disk and swapped in back to RAM?
  • If the statement it not true, what might be the reasons why OS
    would deny the process the virtual memory it asks for? Memory
    overcommitting settings?
1 Answers
  1. JVM allocates memory for different purposes. Of course, this is not just a single chunk of memory. Some JVM structures need to occupy a contiguous chunk, other do not.

  2. If we talk about Java Heap in HotSpot JVM - yes, it is a contiguous range of virtual address space.

  3. The contiguous virtual memory does not have to be backed by contiguous physical memory. Page table is responsible for translating virtual addresses to physical, and it makes possible to map the contiguous virtual address range to fragmented physical pages even after swapping etc.

  4. While it's usually not a problem to find a contiguous virtual address range for Java heap or another JVM structure on a 64-bit system, this can be a real issue on a 32-bit system.

  5. You are right, OS memory overcommitment settings may cause mmap or mprotect call to fail, if the process' total virtual memory size exceeds a threshold.

Related