JMH로 알아보는 오토 박싱의 부하

GC를 회피하는 메모리 관리 기술

자바는 프로그래머가 메모리 관리를 직접 하지 않도록 설계된 언어입니다. 가비지 컬렉션 기술(이하 GC)은 이전 세대의 프로그램에서 있었던 많은 메모리 참조 오류들을 원천적으로 해결하여 크래시나 메모리 오염으로부터 프로그래머들을 해방시켰습니다. 그러나 이러한 특성은 웹 애플리케이션 서버처럼 상태가 별로 없는 프로그램의 동작에는 적합하나, 데이터베이스처럼 대량의 상태를 유지관리해야 하는 프로그램에는 근본적인 한계를 가지고 있습니다. 메모리에 많은 개체들이 유지될수록, GC를 수행하는데 더 많은 시간이 소요됩니다. 단순히 사용되지 않는 쓰레기 개체를 찾는 것 뿐만 아니라, 단편화를 해결하기 위해 메모리 재배치를 수행하면서 많은 메모리 복사를 유발하기 때문입니다. 많은 웹 서비스들이 수천만 건 이상의 세션 정보나 데이터들을 자체 캐싱하는 대신 C로 구현된 memcached나 redis 같은 외부 데몬에 캐싱하는 것은 이런 이유도 깔려있습니다. 그렇다면 아예 방법이 없는 것인가? 그렇지 않습니다. 바로 오프힙 메모리입니다. ### 다이렉트 버퍼의 유래 DirectByteBuffer는 자바 1.4 시절 NIO 기술과 함께 등장했습니다. JNI로 직접 C 라이브러리를 자바에 링크시켜 본 경험이 있다면 쉽게 이해하겠지만, 자바 월드에서 네이티브 월드로 넘어갈 때는 메모리 복사가 일어납니다. 자바 코드에서 참조하는 배열의 메모리는 [불연속적이거나 네이티브 콜을 한 직후에 GC로 삭제될 수도 있기 때문에](http://docs.oracle.com/javase/7/docs/technotes/guides/jni/spec/design.html#wp1265), 자바가상머신은 시스템 콜 호출 시 별도의 메모리 공간에 입력 데이터를 복사해서 사용합니다. 초기 버전의 자바는 디스크나 네트워크 등 I/O를 수행하면서 빈번한 메모리 복사가 발생하므로 많은 성능 저하가 있을 수 밖에 없었고, 자바 1.4부터 I/O 시 반복적으로 복사를 하지 않도록 다이렉트 버퍼를 제공하기 시작했습니다. 다이렉트 버퍼는 불필요한 복사를 회피할 수 있는 대신, 연속적인 메모리 공간 할당, 참조 정보 관리로 인해 자바 힙 메모리에 비해 할당과 접근 모두 상대적으로 느립니다. 그러나 여기서 중요한 특징은 [GC 범위의 바깥](http://docs.oracle.com/javase/8/docs/api/java/nio/ByteBuffer.html)에 있다는 사실입니다. 다이렉트 버퍼는 GC의 영향에서 벗어날 수 있으므로, 메모리 재배치로 인한 수십 초 단위의 GC 수행을 회피할 수 있습니다. > The buffers returned by this method typically have somewhat higher allocation and deallocation costs than non-direct buffers. **The contents of direct buffers may reside outside of the normal garbage-collected heap**, and so their impact upon the memory footprint of an application might not be obvious. ### 다이렉트 버퍼의 생명주기 제어 위의 인용문구에서 보이듯이, 다이렉트 메모리의 사용량은 단순 힙 사용량으로는 관측되지 않습니다. 이러한 특성은 GC 자체에도 영향을 주는데, 예를 들어 다이렉트 메모리를 더 이상 어디에서도 참조하지 않는데도 불구하고 즉시 GC로 제거되지 않는 현상이 발생합니다. 실제로는 가용 메모리가 있는데도 불구하고 아래와 같이 다이렉트 메모리 할당에 실패할 수 있습니다. ``` java.lang.OutOfMemoryError: Direct buffer memory at java.nio.Bits.reserveMemory(Bits.java:658) at java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123) at java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:306) ``` 강제로 System.gc()를 호출하지 않는 이상, 다이렉트 바이트버퍼를 해제하려면 다른 방법을 고안해야 합니다. 이 이슈 때문에 다이렉트 메모리를 응용하는 애플리케이션들은 흔히 문서화되지 않은 아래 방법을 사용합니다. ```java ByteBuffer bb = ByteBuffer.allocateDirect(10000); Method cleanerMethod = bb.getClass().getMethod("cleaner"); cleanerMethod.setAccessible(true); Object cleaner = cleanerMethod.invoke(bb); Method cleanMethod = cleaner.getClass().getMethod("clean"); cleanMethod.setAccessible(true); cleanMethod.invoke(cleaner); ``` 본래는 Finalizer에 의해 호출될 다이렉트 바이트버퍼의 내부 Cleaner 메소드를 리플렉션을 이용해서 직접 호출하는 것입니다. 그러나 이제 문제는 새로운 차원으로 옮겨가게 됩니다. 다이렉트 바이트버퍼의 메모리를 직접 할당하고 해제한다는 것은, 기존의 C/C++와 같은 언어에서 직접 메모리를 할당하고 해제했던 것처럼 메모리에 대한 모든 생명주기를 직접 책임져야 한다는 의미입니다. 특히, 멀티스레드 환경에서는 개체의 참조를 정확하게 계산하도록 레퍼런스 카운터 등을 이용해야 합니다. 만약, 이미 해제해버린 메모리를 대상으로 데이터를 쓰거나 읽으려고 시도한다면, 크래시를 피할 수 없습니다. 예를 들어 아래의 코드는 아주 쉽게 크래시를 유도합니다. ```java for (int i = 0; i < 1000; i++) { ByteBuffer bb = ByteBuffer.allocateDirect(10000); Method cleanerMethod = bb.getClass().getMethod("cleaner"); cleanerMethod.setAccessible(true); Object cleaner = cleanerMethod.invoke(bb); Method cleanMethod = cleaner.getClass().getMethod("clean"); cleanMethod.setAccessible(true); cleanMethod.invoke(cleaner); byte[] buf = new byte[10000]; bb.put(buf); } ``` 윈도우 환경의 크래시 발생 예 ``` # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007fff1c899f58, pid=10756, tid=16228 # # JRE version: Java(TM) SE Runtime Environment (8.0_60-b27) (build 1.8.0_60-b27) # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.60-b23 mixed mode windows-amd64 compressed oops) # Problematic frame: # C [ntdll.dll+0x39f58] # # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows # # An error report file with more information is saved as: # hs_err_pid10756.log ``` 이 뿐만 아니라, 오프힙 메모리는 바이트 배열에 불과하기 때문에 반드시 바이트 직렬화 과정을 거쳐야 합니다. 예를 들어, 16909060라는 정수 값이 있다면, 01 02 03 04로 인코딩해야 합니다. 여기에 더해서 다이렉트 바이트버퍼의 할당과 해제는 상대적으로 훨씬 느리기 때문에, 오프힙 메모리의 응용에는 버퍼 풀링을 포함한 정교한 아키텍처 설계가 필요합니다. 로그프레소는 오프힙 메모리 기술을 통해 GC 문제를 회피하고 수백 기가에 이르는 데이터를 압축된 상태로 캐싱하며 쿼리 실행을 가속합니다.

2017-01-03

10배 빠르게 통계 처리하기

자바로 개발된 많은 엔터프라이즈 응용프로그램들은 일반적으로 데이터베이스에 의존하여 데이터를 처리하지만, 처리해야 할 데이터가 너무 크거나 실시간 집계가 필요한 경우 자바로 직접 개발하여 통계를 내기도 합니다. 현재는 데스크탑에서도 4개 이상의 멀티코어를 사용하기 때문에, 서버에서는 수십 개의 스레드가 데이터를 처리하여 집계하는 경우를 흔하게 볼 수 있습니다. 중급 이상의 개발자라면 프로세서가 지원하는 CAS (Compare-And-Swap) 인스트럭션을 기반으로 한 AtomicInteger나 AtomicLong 클래스를 이용하여 병렬 집계 처리를 하겠지만, 자바 8은 멀티코어 환경에서 성능이 더 나은 옵션을 제공합니다. 바로 LongAdder 클래스입니다. **AtomicLong 테스트 코드** ```java import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.AtomicLong; public class Benchmark { private AtomicLong counter = new AtomicLong(0); public class Counter implements Runnable { @Override public void run() { for (int i = 0; i < 10000000; i++) counter.incrementAndGet(); } } public void run() throws InterruptedException { int cores = Runtime.getRuntime().availableProcessors(); ExecutorService pool = Executors.newFixedThreadPool(cores); long begin = System.currentTimeMillis(); for (int i = 0; i < cores; i++) pool.submit(new Counter()); pool.shutdown(); pool.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); long end = System.currentTimeMillis(); System.out.println(counter.get()); System.out.println((end - begin) + "ms"); } public static void main(String[] args) throws Exception { new Benchmark().run(); } } ``` **LongAdder 테스트 코드** ```java import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; import java.util.concurrent.atomic.LongAdder; public class Benchmark { private LongAdder counter = new LongAdder(); public class Counter implements Runnable { @Override public void run() { for (int i = 0; i < 10000000; i++) counter.increment(); } } public void run() throws InterruptedException { int cores = Runtime.getRuntime().availableProcessors(); ExecutorService pool = Executors.newFixedThreadPool(cores); long begin = System.currentTimeMillis(); for (int i = 0; i < cores; i++) pool.submit(new Counter()); pool.shutdown(); pool.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS); long end = System.currentTimeMillis(); System.out.println(counter.sum()); System.out.println((end - begin) + "ms"); } public static void main(String[] args) throws Exception { new Benchmark().run(); } } ``` **측정 결과 #1** - 인텔 코어 i7-4770 3.4GHz, 4 코어, 8 스레드 - AtomicLong: 1546ms, 1542ms, 1534ms - LongAdder: 155ms, 141ms, 143ms **측정 결과 #2** - 인텔 제온 E5-2687W v3 3.1GHz, 20 코어, 40 스레드 - AtomicLong: 6701ms, 7126ms, 6880ms - LongAdder: 351ms, 349ms, 332ms ### 성능 차이의 원인 멀티스레드 응용에서 AtomicLong을 이용해서 집계를 수행하는 경우, 모든 코어의 CPU 사용율이 100%에 근접하기 때문에 최대 속도로 동작하고 있다고 단순하게 생각하기 쉽습니다. 실제로는 같은 메모리 변수에 대해 다수의 코어가 경합을 벌이게 되면서, 값 변경이 성공하게 될 때까지 무한히 재시도 하는 상태가 됩니다. 스레드 수가 많을수록 더 극심한 경합이 발생하고 성능이 더 떨어집니다. LongAdder는 여러 개의 카운터로 구성된 배열을 이용해서 코어 간 경합이 발생할 확률을 떨어뜨립니다. 마지막에 각 카운터를 합산하여 최종 결과를 계산하는 방식으로, 집계를 수행할 때는 경합을 최소화하고 정확한 결과를 얻을 수 있습니다. LongAdder는 멀티스레드 집계 상황에서 성능이 좋은 대신, 메모리를 상대적으로 많이 사용합니다. 아래 코드에서 보이듯이 LongAdder는 경합이 발생하면 2배씩 카운터 배열을 확장합니다. ```java else if (cellsBusy == 0 && casCellsBusy()) { try { if (cells == cs) // Expand table unless stale cells = Arrays.copyOf(cs, n << 1); } finally { cellsBusy = 0; } collide = false; continue; // Retry with expanded table } ``` 집계 카운터가 많은 경우, 이러한 메모리 사용량은 받아들이기 어려울 수 있습니다. 로그프레소는 하드웨어 환경에 따라 적절한 메모리를 사용하면서 백오프(Backoff)를 이용해 경합을 감소시키는 알고리즘을 사용합니다.

2016-12-28

GraalVM 소개

로그프레소 빅데이터 플랫폼은 복잡한 사용자 분석 기능 확장을 지원하기 위하여 2014년 이래 그루비, 자바스크립트 엔진을 내장하여 지원하고 있습니다. 지금까지는 자바스크립트를 구동하는데 Nashorn 엔진을 사용했는데요. 자바 11이 출시되면서 Nashorn은 제거 예정 상태로 변경되었고 GraalVM으로 대체를 권고하고 있습니다. 이번 글에서는 GraalVM에 대한 전반적인 개요를 소개합니다. ## GraalVM 개발 배경 GraalVM은 2005년에 썬 마이크로시스템즈에서 Maxine 가상머신 프로젝트로 시작되었습니다. 자바 가상머신(JVM)은 C++ 언어로 구현되어 있는데, 이 프로젝트의 목표는 자바 가상머신 전체를 자바 언어로 다시 작성하는 것이었습니다. 그러나 모든 코드를 한 번에 다 갈아엎는다는 것이 현실적으로 매우 달성하기 어렵기 때문에, 기존 핫스팟 런타임을 최대한 재사용하면서 플러그인으로 JIT 컴파일러를 끼워넣는 방향으로 선회하여 오늘에 이르렀습니다. ## GraalVM 구성  GraalVM JIT 컴파일러는 자바 9 버전에 추가된 JVMCI (JVM 컴파일러 인터페이스)를 이용하여 기존 핫스팟 런타임에 플러그인 되는 구조로 동작합니다. 자바나 스칼라 같은 JVM 기반 언어는 GraalVM JIT 컴파일러의 최적화를 통해 성능 향상을 기대할 수 있습니다. 그 위에 Truffle 프레임워크가 올라가는데, 이는 자바스크립트, R, 파이썬, 루비 등 JVM 기반이 아닌 기존 언어의 새로운 구현을 지원합니다. ## GraalVM 활용 분야 * 기존 자바 응용 프로그램의 성능 향상 * 트위터의 경우 GraalVM을 적용해서 기존 Scala 코드에 대해 약 20%의 성능 향상 달성 * 다양한 언어 확장 * 자바 코드에서 자바스크립트, R, 파이썬, LLVM IR, 웹 어셈블리 실행 가능 * 각 언어별 라이브러리 활용 가능 (예: R이나 파이썬에서 데이터 분석 후 자바스크립트로 출력) * 고성능이 필요한 모듈을 C/C++로 구현 * 호스트 접근 필터링 기능으로 스크립트 실행 시 보안성 향상 * 네이티브 이미지 생성 * AOT 컴파일을 통해 부팅 시간 단축, 이미지 크기 최소화 * 특히 최근의 컨테이너 기반 마이크로서비스 아키텍처에 활용성 높음 * 기존 언어의 대량 메모리 사용 지원 * 자바 가상머신은 수십 년간 GC를 개선하여 테라바이트 단위의 힙 메모리까지 지원 가능 * GraalVM 기반으로 구현된 기존 언어는 대량 메모리 사용 시나리오도 지원할 수 있음 ## GraalVM 구동 방법 OpenJDK 11 버전 이상을 사용하고 있다면 아래와 같이 부팅 스위치를 추가하여 GraalVM JIT을 활성화 할 수 있습니다. 아래 구성은 Graal JIT만 사용하는 최소 구성입니다: ``` -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI --module-path=graalvm --upgrade-module-path=graalvm/compiler.jar ``` 아래 3개의 파일이 graalvm 위치에 있어야 합니다. (20.0.0 버전 기준으로 약 21MB) * [compiler.jar](https://repo1.maven.org/maven2/org/graalvm/compiler/compiler/20.0.0/compiler-20.0.0.jar) * [graal-sdk.jar](https://repo1.maven.org/maven2/org/graalvm/sdk/graal-sdk/20.0.0/graal-sdk-20.0.0.jar) * [truffle-api.jar](https://repo1.maven.org/maven2/org/graalvm/truffle/truffle-api/20.0.0/truffle-api-20.0.0.jar) 시스템 프로퍼티에 아래 속성들이 추가되면 정상적으로 GraalVM이 핫스팟 런타임에 플러그인 된 것입니다. ``` jdk.internal.vm.ci.enabled=true jdk.module.path=graalvm jdk.module.upgrade.path=graalvm/compiler.jar ``` 다음 글에서는 자바스크립트, 파이썬 코드를 실제 구동하는 방법에 대해 알아보겠습니다. ### 레퍼런스 * [Maxine Virtual Machine](https://en.wikipedia.org/wiki/Maxine_Virtual_Machine) * [Running GraalJS on stock JDK11](https://github.com/graalvm/graal-js-jdk11-maven-demo) * [Understanding How Graal Works - a Java JIT Compiler Written in Java](https://chrisseaton.com/truffleruby/jokerconf17/)

2020-05-10