Memory size feasible via Virtual Memory vs RAM

Question

I am trying to instantiate a huge ArrayList

List<Integer> list = new ArrayList<Integer>(Integer.MAX_VALUE);  

Running it in eclipse I get:

java.lang.OutOfMemoryError: Requested array size exceeds VM limit  

If I do:

List<Integer> list = new ArrayList<Integer>(Integer.MAX_VALUE - 2);  

I get a different error:

Java HotSpot(TM) 64-Bit Server VM warning: INFO: os::commit_memory failed; error='The paging file is too small for this operation to complete'   

#
# there is insifficent memory for the Java Runtime Environment to continue.   

I start the program with the following setting in the run configurations in eclipse:
-Xmx8G

So what is the problem here? Even if I increase to -Xmx16G it still gives the same error

Update
I am bit confused, does the actual size of RAM matter here? Dont processes have access to unlimited virtual memory thanks to paging?

Answer 1

I am bit confused, does the actual size of RAM matter here?

Yes, it does.

Don't processes have access to unlimited virtual memory thanks to paging?

Yes they do... modulo that you need disk space to hold the virtual memory pages. Indeed, "that* is why you are getting this error:

The paging file is too small for this operation to complete.

This "fix" would be to make the paging file bigger. That has to be done at the OS level.

However , paging means that the operating system has to copy pages from disk to memory when they are needed. And to make room for them it has to copy other (dirty) pages from RAM to disk. All of this copying uses CPU and disk I/O bandwidth and slows down your program.

A typical (C / C++) program can often cope with this to a degree, depending on the application's memory access patterns. But in Java you have the problem that occasionally the GC runs. For a period of time, the GC will be accessing objects in a large number of pages in (essentially) random order. It is worse for a "full" garbage collection.

If the size of the set pages being accessed by an application (ie the "working set") is larger than the number of available RAM pages, you can end up "thrashing"; ie saturating the I/O system with reads and writes of pages. That is really bad for performance. In extreme cases it can make the OS unresponsive.

Hence, running a Java application with a heap that is larger than the available physical RAM is a potentially dangerous thing to do.