Out-of-memory error occurs frequently in the java programs. My question is simple: when exceeding the memory limitation, why java directly kill the program rather than swap it out to the disk? I think memory paging/swapping strategy is frequently used in the modern operating system and programming languages like c++ definitely supports swapping. Thanks.
-
3Because the JVM won't exceed the memory you've allocated for it. That's what the -Xmx parameter is for (the default is something like 1G or 1/4 of your total memory). – Kayaman Jul 18 '14 at 14:32
-
"C++ definitely supports swapping". I'd love to see an example of that. – Gimby Jul 18 '14 at 14:46
-
@Gimby I think I found the function: http://man7.org/linux/man-pages/man2/mmap.2.html It allows you to map a file in, which is similar. – Octavia Togami Jul 18 '14 at 14:54
-
Memory mapping is indeed a technique that major OSes provide (even Windows). Not C/C++. – Gimby Jul 18 '14 at 14:58
3 Answers
@Pimgd is sorta on track: but @Kayaman is right. Java doesn't handle memory besides requesting it from the system. C++ doesn't support swapping, it requests memory from the OS and the OS will do the swapping. If you request enough memory for your application with -Xmx
, it might start swapping because the OS thinks it can.

- 4,186
- 4
- 31
- 49
-
On further looking, C might do swapping support. Not quite sure. – Octavia Togami Jul 18 '14 at 14:46
-
But why java bothers to ask users to set the memory limitation? At most of the time users expect their programs to run smoothly without any interruption. As a user, I would always like to set -Xmx to an extremely large number to guarantee no out-of-memory error can occur. If the system supports swapping, then why not rely on the OS? – Frank Jul 18 '14 at 14:58
-
Because Java runs a virtual machine. That's why it's called the Java Virtual Machine, or JVM. It's a design choice that was probably made to support the runtime optimizing that it (the JVM) does. – Octavia Togami Jul 18 '14 at 15:00
Because Java is cross-platform. There might not be a disk.
Other reasons could be that such a thing would affect performance and the developers didn't want that to happen (because Java already carries a performance overhead?).

- 5,983
- 1
- 30
- 45
-
Java carries an initial performance overhead but the JVM can optimize during runtime to perform better than C/C++. See http://stackoverflow.com/questions/538056/jit-compiler-vs-offline-compilers – Octavia Togami Jul 18 '14 at 14:37
-
I know Java can be pretty fast, but I'd hate to be the one that has to write a garbage collector that also has to deal with paginated memory on disk (whilst not impacting application performance, of course)... They (java devs) made this decision a long time ago... – Pimgd Jul 18 '14 at 14:39
-
1Java does paging with the GC; it is slow. http://publib.boulder.ibm.com/infocenter/javasdk/tools/index.jsp?topic=%2Fcom.ibm.java.doc.igaa%2F_1vg0001143f2181-11a9b04924e-7ffc_1001.html – Octavia Togami Jul 18 '14 at 14:46
-
I knew that I'd learn something if I stuck around this question long enough =D – Pimgd Jul 18 '14 at 14:47
A few words about paging. Virtual memory using paging - storing 4K (or similar) chunks of any program that runs on a system - is something an operating system can or cannot do. The promise of an address space only limited by the capacity of a machine word used to store an address sounds great, but there's a severe downside, which is called thrashing
. This happens when the number of page (re)loads exceeds a certain frequency, which in turn is due of too many processes requesting too much memory in combination with non-locality of memory accesses of those processes. (A process has a good locality if it can execute long stretches of code while accessing only a small percentage of its pages.)
Paging also requires (fast) secondary storage.
The ability to limit your program's memory resources (as in Java) is not only a burden; it must also be seen as a blessing when some overall plan for resource usage needs to be devised for a, say, server system.

- 31,114
- 3
- 29
- 42