From What Linux Kernel/Libc Version Is Java Runtime.Exec() Safe with Regards to Memory

From what Linux kernel/libc version is Java Runtime.exec() safe with regards to memory?

This is pretty much the way *nix (and linux) have worked since the dawn of time(or atleat the dawn of mmus).

To create a new process on *nixes you call fork(). fork() creates a copy of the calling process with all its memory mappings, file descriptors, etc. The memory mappings are done copy-on-write so (in optimal cases) no memory is actually copied, only the mappings. A following exec() call replaces the current memory mapping with that of the new executable. So, fork()/exec() is the way you create a new process and that's what the JVM uses.

The caveat is with huge processes on a busy system, the parent might continue to run for a little while before the child exec()'s causing a huge amount of memory to be copied cause of the copy-on-write. In VMs , memory can be moved around a lot to facilitate a garbage collector which produces even more copying.

The "workaround" is to do what you've already done, create an external lightweight process that takes care of spawning new processes - or use a more lightweight approach than fork/exec to spawn processes (Which linux does not have - and would anyway require a change in the jvm itself). Posix specifies the posix_spawn() function, which in theory can be implemented without copying the memory mapping of the calling process - but on linux it isn't.

Which memory is used for external process run from java - java heap space or OS memory?

You are starting a separate OS-level native process -- it will have nothing to do with the JVM memory, heap or otherwise.

mysqldump (Errcode: 2) trying do backup from java in linux (server) with wildfly

I found the solution:

in linux server works different that windows,

we need use

//for linux server          
String[] cmdarray = {"/bin/sh","-c",command};
process = Runtime.getRuntime().exec(cmdarray);

java xmx parameter seems not working in CentOS 7.6, how to limit java 11 process memory

The -Xmx flag only limits the Java heap size. It doesn't constrains the JVM's other use of memory. The JVM uses / consumes off-heap memory for lots of things:

• The shared memory segments for the java executable itself
• Dynamically loaded (native) libraries.
• The JVM's (C++) native heap
• The Java threads' stack segments
• The JVM's metaspace
• Memory segments for mapped files, etc.

Depending on the application and what it does, this odd-heap memory could be significant.

(The -Xmx option does work, but not in the way that you think it does.)

---

Why the Java did not OOM itself and using so much memory ...

Presumably because it hasn't totally filled the Java heap. (Or hasn't failed to allocate an off-memory segment.)

... and finally killed by linux kernel?

The OOM killer doesn't actually kill based on the absolute amount of (physical or virtual) memory that a process uses. What it is actually doing is measuring the demand that the various processes are placing on the virtual memory system (swapping) and picking the process that seems to be causing the system to thrash.

A JVM running a full garbage collection on a system that with a limited amount of RAM is liable to generate a lot of paging, and is liable to be an OOM killer target.

---

Related Topics