<div id="readability-page-1" class="page"><div>
<p>2015년 글의 핵심은 힙이 큰 Java 프로세스가 외부 프로세스를 실행하면 <code>Cannot allocate memory</code> 예외가 날 수 있다는 것이었습니다. 원인은 <code>fork()</code>에 있었습니다. <code>fork()</code>는 부모와 같은 자식 프로세스를 만드는데, Linux는 쓰기 시 복사(copy-on-write)로 실제 페이지 복사는 미루지만 페이지 테이블은 복사하고, 커널의 메모리 overcommit 정책에 따라 자식이 쓸지도 모르는 메모리를 미리 계산해서 거절하기도 합니다. 자식은 곧바로 <code>exec()</code>로 작은 프로그램으로 바뀔 테지만 커널은 그 사실을 알 수 없습니다.</p>
<p>이 문제는 JDK 쪽과 Linux 쪽에서 각각 해소됐습니다.</p>
<div>
<h3 id="jdk의_실행_방식_변천">JDK의 실행 방식 변천</h3>
<p>JDK가 Linux에서 하위 프로세스를 만드는 방식은 <code>jdk.lang.Process.launchMechanism</code> 시스템 속성으로 정해집니다. 기본값의 변천은 아래와 같습니다.</p>
<table>
<colgroup>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>JDK</th>
<th>Linux에서의 변화</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>6</p></td>
<td><p><code>fork()</code> + <code>exec()</code></p></td>
</tr>
<tr>
<td><p>7</p></td>
<td><p><code>vfork()</code>가 기본값이 됨 (<a href="https://bugs.openjdk.org/browse/JDK-6868160">JDK-6868160</a>)</p></td>
</tr>
<tr>
<td><p>12</p></td>
<td><p><code>POSIX_SPAWN</code>을 선택 옵션으로 추가 (<a href="https://bugs.openjdk.org/browse/JDK-8212828">JDK-8212828</a>). 11.0.4에도 백포트</p></td>
</tr>
<tr>
<td><p>13</p></td>
<td><p><code>POSIX_SPAWN</code>이 기본값이 됨 (<a href="https://bugs.openjdk.org/browse/JDK-8213192">JDK-8213192</a>)</p></td>
</tr>
<tr>
<td><p>25</p></td>
<td><p><code>VFORK</code>를 지정하면 deprecated 경고 출력 (<a href="https://bugs.openjdk.org/browse/JDK-8357180">JDK-8357180</a>)</p></td>
</tr>
<tr>
<td><p>27</p></td>
<td><p><code>VFORK</code> 제거. 지정하면 <code>FORK</code>로 동작 (<a href="https://bugs.openjdk.org/browse/JDK-8357090">JDK-8357090</a>)</p></td>
</tr>
</tbody>
</table>
<p>2015년에는 "JDK 7부터 Linux에서 <code>vfork()</code>를 쓰니 메모리 문제는 피할 수 있다"가 결론이었습니다. <code>vfork()</code>는 페이지 테이블을 복사하지 않고 자식이 부모의 메모리 이미지 안에서 <code>exec()</code>까지만 실행하므로 메모리 문제는 없습니다. 대신 자식이 <code>exec()</code> 전에 부모의 스택이나 시그널 처리를 건드릴 위험이 있고, JDK는 그 사이에 파일 디스크립터 정리 같은 작업을 해야 해서 <code>vfork()</code>의 사용 규칙을 어길 수밖에 없었습니다. JDK-8357090의 설명대로 그 위험 때문에 JDK 27부터 <code>VFORK</code> 옵션이 사라집니다. JDK 25에서 이 옵션을 지정하면 아래 경고가 표준 오류에 출력됩니다.</p>
<div>
<pre><code data-lang="text">$ java -Djdk.lang.Process.launchMechanism=VFORK ProcessRunner
VFORK MODE DEPRECATED
The VFORK launch mechanism has been deprecated for being dangerous.
It will be removed in a future java version. Either remove the
jdk.lang.Process.launchMechanism property (preferred) or use FORK mode
instead (-Djdk.lang.Process.launchMechanism=FORK).</code></pre>
</div>
<p>지금의 기본값인 <code>posix_spawn()</code>은 시스템 콜이 아니라 C 라이브러리 함수입니다. fork와 exec, 그 사이의 준비 작업을 한 묶음으로 제공한다는 점에서 Windows의 <code>CreateProcess()</code>와 닮았습니다. JDK는 이 함수로 <code>jspawnhelper</code> 라는 작은 실행 파일을 먼저 띄우고, <code>jspawnhelper</code> 가 파이프로 넘겨받은 설정에 따라 파일 디스크립터와 작업 디렉터리를 정리한 뒤 실제 명령을 다시 <code>exec()</code>합니다. 이 구조는 JDK 소스의 <a href="https://github.com/openjdk/jdk/blob/master/src/java.base/unix/native/libjava/ProcessImpl_md.c">ProcessImpl_md.c</a> 상단 주석에 설명되어 있습니다.</p>
<p>strace로 보면 두 번의 <code>execve</code> 가 그대로 드러납니다. 아래는 <code>echo hello</code> 를 실행하는 <a href="https://github.com/benelog/blog/tree/master/examples/java-external-process/ProcessRunner.java">ProcessRunner.java</a>를 기본 설정으로 실행했을 때의 시스템 콜 중 프로세스 생성과 관련된 부분입니다. 경로는 줄였습니다.</p>
<div>
<pre><code data-lang="text">$ strace -f -e trace=clone,clone3,vfork,execve -o trace.txt java ProcessRunner
$ grep -v CLONE_THREAD trace.txt | grep -E 'clone|vfork|execve'
285583 clone3({flags=CLONE_VM|CLONE_VFORK|CLONE_CLEAR_SIGHAND, exit_signal=SIGCHLD, stack=..., stack_size=0x9000}, 88 &lt;unfinished ...&gt;
285603 execve("$JAVA_HOME/lib/jspawnhelper", ["$JAVA_HOME/lib/jspawnhelper", "25+36-LTS", "10:11:13"], ...) = 0
285603 execve("/usr/bin/echo", ["echo", "hello"], ...) = 0</code></pre>
</div>
<p><code>vfork()</code> 시스템 콜은 나오지 않습니다. glibc 2.39의 <code>posix_spawn()</code>은 <code>clone3</code> 시스템 콜에 <code>CLONE_VM</code> 과 <code>CLONE_VFORK</code> 플래그를 주어 <code>vfork()</code>와 같은 효과를 냅니다. 이것이 다음 절의 내용입니다. 같은 프로그램을 <code>-Djdk.lang.Process.launchMechanism=FORK</code> 로 실행하면 <code>CLONE_VM</code> 플래그 없이 <code>clone</code> 시스템 콜을 부르고, <code>jspawnhelper</code> 없이 곧바로 <code>/usr/bin/echo</code> 를 <code>execve</code>합니다.</p>
</div>
<div>
<h3 id="glibc와_커널의_변화">glibc와 커널의 변화</h3>
<p>JDK가 <code>posix_spawn()</code>으로 옮겨 갈 수 있었던 배경에는 glibc의 변화가 있습니다. <a href="https://man7.org/linux/man-pages/man3/posix_spawn.3.html">posix_spawn(3)</a> 매뉴얼에 따르면 glibc 2.24(2016년 8월)부터 <code>posix_spawn()</code>은 <code>CLONE_VM</code> 과 <code>CLONE_VFORK</code> 플래그로 <code>clone()</code>을 호출합니다. 자식에게 따로 할당한 스택을 주고 시그널을 막아 두기 때문에 <code>vfork()</code>의 위험 요소 두 가지, 즉 부모 스택 손상과 시그널 오배달이 없습니다. JDK 소스의 주석은 이를 "vfork의 성능을 위험 없이 흉내 낸다"고 표현합니다. Alpine Linux가 쓰는 musl은 처음부터 같은 방식이었습니다. 2015년 글에서 "glibc가 <code>posix_spawn()</code>을 구현할 때 가능하면 <code>vfork()</code>를 쓴다"고 적었는데, 그 글이 나온 이듬해에 glibc가 <code>vfork()</code>를 버린 것입니다.</p>
<p><code>vfork()</code> 시스템 콜 자체는 Linux 커널에 그대로 있습니다. <a href="https://man7.org/linux/man-pages/man2/vfork.2.html">vfork(2)</a> 매뉴얼은 여전히 <code>vfork()</code>를 <code>CLONE_VM | CLONE_VFORK | SIGCHLD</code> 플래그를 준 <code>clone()</code>과 같다고 설명하고, POSIX.1-2008에서 명세가 삭제됐다는 사실도 함께 적고 있습니다. 즉 JDK가 <code>VFORK</code>를 없앤 이유는 커널이 바뀌어서가 아니라 JDK 자신이 <code>vfork()</code>와 <code>exec()</code> 사이에서 하던 작업이 안전하지 않아서입니다.</p>
<p>커널 쪽에서는 overcommit 휴리스틱이 바뀌었습니다. <code>vm.overcommit_memory</code> 의 기본값 0은 "명백한 overcommit만 거절하는" 모드입니다. 커널 5.2 이전에는 이 판정에 여유 메모리, 페이지 캐시, 스왑 여유분 등을 합산한 값을 썼습니다. 힙 매핑이 여유 메모리보다 크면 <code>fork()</code>가 그 매핑을 복제할 때 요구하는 크기가 이 값을 넘어서 <code>ENOMEM</code> 이 났습니다. 2015년 글에 나온 <code>Cannot allocate memory</code> 가 바로 이 경우입니다. 커널 5.2에 들어간 <a href="https://lkml.iu.edu/hypermail/linux/kernel/1904.1/05420.html">mm: fix false-positive OVERCOMMIT_GUESS failures</a> 패치는 이 계산을 "요청 크기가 전체 RAM과 스왑의 합을 넘는지"만 보도록 단순화했습니다. 그래서 지금의 기본 설정에서는 <code>FORK</code> 모드를 써도 힙 크기 때문에 <code>fork()</code>가 실패하는 일이 거의 없습니다. 다만 <code>vm.overcommit_memory=2</code> 로 overcommit을 금지한 서버에서는 <code>fork()</code> 시점에 부모 크기만큼의 commit이 여전히 계산되므로 예전 문제가 그대로 재현됩니다. 데이터베이스 서버 권고 설정을 따라 이 값을 2로 둔 장비에 Java 애플리케이션이 함께 올라가는 경우가 있습니다.</p>
</div>
<div>
<h3 id="큰_힙에서_fork와_posix_spawn의_실행_지연">큰 힙에서 FORK와 POSIX_SPAWN의 실행 지연</h3>
<p>메모리 할당 실패가 사라졌어도 <code>fork()</code>가 페이지 테이블을 복사한다는 사실은 변하지 않았습니다. 힙이 클수록 복사할 페이지 테이블도 커집니다. 힙을 미리 할당한 상태에서 <code>true</code> 명령을 30번 실행하는 데 걸린 시간을 실행 방식별로 재 봤습니다. 측정 코드는 <a href="https://github.com/benelog/blog/tree/master/examples/java-external-process/SpawnBench.java">SpawnBench.java</a>이고, <code>-XX:+AlwaysPreTouch</code> 옵션으로 힙 전체를 실제 메모리에 올린 뒤 측정했습니다. 두 번 실행한 값입니다.</p>
<table>
<colgroup>
<col>
<col>
<col>
</colgroup>
<thead>
<tr>
<th>힙 크기</th>
<th>POSIX_SPAWN (ms/회)</th>
<th>FORK (ms/회)</th>
</tr>
</thead>
<tbody>
<tr>
<td><p>256MB</p></td>
<td><p>1.5, 1.2</p></td>
<td><p>15.9, 20.2</p></td>
</tr>
<tr>
<td><p>2GB</p></td>
<td><p>1.6, 1.9</p></td>
<td><p>120.8, 140.7</p></td>
</tr>
<tr>
<td><p>8GB</p></td>
<td><p>2.0, 2.1</p></td>
<td><p>243.5, 231.2</p></td>
</tr>
</tbody>
</table>
<p><code>POSIX_SPAWN</code>은 힙 크기와 무관하게 약 2ms이고, <code>FORK</code>는 힙에 비례해서 늘어나 8GB에서는 100배가 넘게 차이가 났습니다. <code>fork()</code>가 페이지 테이블을 복사하는 동안 커널은 부모 프로세스의 주소 공간 잠금(mmap_lock)을 쓰기 모드로 잡습니다. 그래서 호출한 스레드만 멈추는 것이 아니라 같은 시간에 메모리 매핑을 바꾸려는 다른 스레드도 기다립니다. 웹 애플리케이션이 요청마다 외부 명령을 실행한다면 이 차이는 응답 시간에 그대로 나타납니다. <code>POSIX_SPAWN</code> 기본값을 굳이 <code>FORK</code>로 바꿀 이유가 없는 또 하나의 근거입니다.</p>
</div>
<div>
<h3 id="jspawnhelper와_관련된_새_주의점">jspawnhelper와 관련된 새 주의점</h3>
<p><code>posix_spawn()</code> 방식은 <code>jspawnhelper</code> 실행 파일에 의존하기 때문에 예전에는 없던 실패 유형이 하나 생겼습니다. JDK가 실행 중인 상태에서 같은 경로의 JDK가 새 버전으로 덮어씌워지면, 이미 메모리에 올라간 JVM이 새 버전의 <code>jspawnhelper</code> 를 실행하게 됩니다. Ubuntu의 unattended-upgrades처럼 패키지를 자동으로 갱신하는 환경에서 실제로 일어나는 일입니다. JDK 23의 <a href="https://bugs.openjdk.org/browse/JDK-8325621">JDK-8325621</a>부터 <code>jspawnhelper</code> 가 자신을 실행한 JVM과 버전이 같은지 검사해서 다르면 아래와 같은 예외를 던집니다. 이 검사는 22.0.2, 21.0.4, 17.0.13에도 백포트됐습니다.</p>
<p>JDK 25 디렉터리를 복사해서 Java 프로그램을 띄운 뒤, 실행 중에 <code>lib/jspawnhelper</code> 를 JDK 17의 것으로 바꿔치기해서 이 상황을 재현했습니다. 표준 오류에 <code>jspawnhelper</code> 의 메시지가 먼저 찍히고, 이어서 원인 후보와 해결책까지 적힌 예외가 납니다.</p>
<div>
<pre><code data-lang="text">Incorrect Java version: 25+36-LTS
jspawnhelper version 17.0.16+8
This command is not for general use and should only be run as the result of a call to
ProcessBuilder.start() or Runtime.exec() in a java application
Exception in thread "main" java.io.IOException: Cannot run program "echo": Failed to exec spawn helper: pid: 288611, exit code: 1, error: 0 (none)
Possible reasons:
  - Spawn helper ran into JDK version mismatch
  - Spawn helper ran into unexpected internal error
  - Spawn helper was terminated by another process
Possible solutions:
  - Restart JVM, especially after in-place JDK updates
  - Check system logs for JDK-related errors
  - Re-install JDK to fix permission/versioning problems
  - Switch to legacy launch mechanism with -Djdk.lang.Process.launchMechanism=FORK</code></pre>
</div>
<p>앞의 strace 출력에서 <code>jspawnhelper</code> 의 두 번째 인자로 <code>25+36-LTS</code> 가 넘어간 것이 이 버전 검사입니다. 검사가 없던 버전에서는 명령이 조용히 실패하거나 엉뚱하게 동작했으니 예외가 나는 편이 낫습니다. 이 예외를 만나면 메시지대로 JVM을 재시작하는 것 말고는 방법이 없습니다. 운영 관점에서는 JDK를 버전이 들어간 별도 경로에 설치하고 심볼릭 링크만 바꾸거나, 자동 갱신에서 JDK 패키지를 제외하는 것이 예방책입니다.</p>
<p>JDK 소스의 주석은 <code>posix_spawn()</code>이 libc 구현에 따라 버그가 있을 수 있어서 <code>FORK</code> 모드를 예비로 남겨 둔다고 설명합니다. <code>jspawnhelper</code> 관련 오류가 반복되는데 원인을 바로 찾기 어렵다면 <code>-Djdk.lang.Process.launchMechanism=FORK</code> 로 임시 회피할 수 있습니다. 위에서 본 실행 지연을 감수하는 선택입니다.</p>
</div>
</div></div>

Java에서 외부 프로세스를 실행할 때: JDK 25와 Linux 6.x 기준

댓글