근래 최고의 Java 혁신은 GraalVM Native Image가 아닐까

GraalVM의 Native Image가 리눅스 컨테이너에서 Spring Boot 기반 서비스들을 실행하는 데 점점 더 많이 사용되는 이유 중 하나가 메모리 footprint가 기존 서버 JVM처럼 미리 Heap을 전체 할당하는 방식이 아니라는 것일듯.

  • 참고 : Quarkus - SUPERSONIC SUBATOMIC JAVA
    • A Kubernetes Native Java stack tailored for OpenJDK HotSpot and GraalVM, crafted from the best of breed Java libraries and standards. 
memory footprint and first response time comparison



GraalVM의 Native Image는 SubstrateVM이라는 유사 JVM(?)을 사용하는데 그야말로 기판에 사용되는 자바 모듈들을 AOT 방식으로 컴파일해서 붙여가는 방식이라서 이렇게 이름을 붙인듯.
-Xmx 기본값이 unlimited 이다. 와우!

SubstrateVM은 closed world라는 전제로 만들어졌는데 런타임에 사용되는 모듈들은 빌드 타임에도 알 수 있다는 전제이다.
그래서 동적으로 로드되는 자바 코드나 JNI 코드나 다 찾아서 빌드 타임에 미리 함께 빌드되도록 옵션 처리해줘야 한다. 한마디로 상당량의 삽질이 기본 전제된다. ㅠㅠ
그런데 점점 더 활용도가 높아져서 많이 쓰는 모듈들은 (JVM 런타임을 포함해서) 분명 누군가가 이 삽질들을 해놓았을 거라고 기대할 수 있다. 내가 짠 모듈들만 잘 챙기면 많은 경우 해결이 될 것이란 기대...

게다가 graalvm native image는 polyglot이다. 아직 실험적이지만 R과 python 코드를 컴파일할 수 있다. numpy와 pandas 패키지를 포함해서...

서버뿐 아니라 클라이언트 프로그램으로도 java를 좀더 잘 활용할 수 있게 되었다.
대부분 관심이 없겠지만(!) 이제 JavaFX로 작성한 프로그램을 GraalVM Native Image로 쉽게 컴파일할 수 있게 되었다. 윈도우에서 하나의 exe 바이너리로 쉽게 빌드할 수 있게 된 것이다.
물론 앞에서 설명한 대로 jni list나 reflection list 등을 찾아서 지정해주는 약간의 삽질은 감수해야 한다. ㅠㅠ

The architecture of Gluon Substrate

최근 자바는 오라클과 구글의 소송을 거치면서 많이 관심이 줄어들었다.
그럼에도 최근 몇 년을 걸쳐 자바의 가장 놀라운 혁신을 들라면 단연 AOT 컴파일 아이디어를 전면 적용한 GraalVM, 그 중에서도 하나의 바이너리를 만들어주는 GraalVM Native Image를 들겠다.


댓글

이 블로그의 인기 게시물

[Java] Java G1 GC의 특성에 따른 Full GC 회피 튜닝 방법

일론 머스크의 First Principle Thinking (제1원리 기반 사고)

엄밀한 사고(Critical Thinking)란 무엇일까