윤경구의 Log on Java

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.  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 바이너리로 쉽게 ...

python을 사용하는 건 대부분 딥러닝을 포함한 분석 때문이긴 하지만 언어의 간결성 때문에 프로토타입 소프트웨어를 만들 때에도 매우 편리하다. flask 웹 서버가 매우 확장성이 좋은데 template 지원 기능이 기존의 JSP, ASP와는 전혀 다른 방식으로 간편하다. 게다가 matplotlib으로 만든 차트를 웹에서 d3 기반으로 embed하는 것( mpld3 )도 가능하다. 데이터 -> python -> 웹까지 쉽게 연결되는 셈이다. 최근  빅데이터 처리를 위해 JVM 기반인 Spark 위에서 python 프로세스를 fork/exec 시키는 PySpark를 왜 쓰나 분석해보기도 했는데 (데이터 전달과 serialize 오버헤드에도 불구하고) 역시 python이 갖고 있는 Java나 Scala가 주지 못하는 데이터 처리 능력 때문인 것 같다. 시스템적인 측면에서 보면 python을 웹 서버나 분산 미들웨어로 쓰는 건 매우 어리석은 일이라고 볼 수 있어서 (multithread 기반의 concurrency가 global interpreter lock 때문에 몹쓸 놈이 되기 때문) python 기반의 openstack을 toy 시스템 외에 production으로 쓰려는 건 바보같은 짓이라고 생각하는데 Google이 십여년 전에 Google AppEngine이라는 PaaS 서비스를 오픈하면서 python 언어로 먼저 제공하고 그 다음에 Java 언어를 지원했던 이유를 알 것 같다. (클라우드 서비스에서 스케일링은 미들웨어가 아닌 컨테이너와 같은 OS 가상화를 통해 지원하면 되니... process pooling을 사용하거나 중요한 백그라운드 잡을 c/c++로 개발했을 수도...) JVM으로 python을 fork하는 PySpark도 어쨌든 시스템 미들웨어로서 python을 쓰는 것은 무리이지만 데이터 분석은 python으로 하고 싶은 요구사항에서 나온 거라고 생각된다. 데이터 오버헤드 관점에서는 정말 말이 ...

Java 6 중반부터 G1 GC가 나오면서 이 새로운 Java VM GC 정책을 두고 성능 튜닝을 어떻게 할지 고민이 많은 것 같다. 일단 생소하기 때문에 어렵다. 그런데 경험들이 조금씩 쌓이면서 문제점도 꽤 발견되는 것 같다. 먼저 G1GC를 이해하는 데 유용한 사이트이다. Garbage-First Collector Getting Started with the G1 Garbage Collector Understanding G1 GC Logs Tuning Garbage Collection for Mission-Critical Java Applications Controlling GC pauses with the GarbageFirst Collector G1: One Garbage Collector To Rule Them All Garbage First (G1) Garbage Collection Options compare JVM options for public 메일 :  G1 GC clean up time is too long JDK 7부터 기본이 된 G1(garbage first) GC는 JVM의 Heap 메모리를 1MB 정도 크기의 region들로 나눠서 region별로 generation을 지정하여 상당히 효율이 좋지만 튜닝하는 게 까다롭다. (새로운 메모리 처리 구조에 대한 튜닝 경험도 많이 부족해서 더욱 까다롭게 느껴지는 것 같다.) 지금까지 널리 알려진 문제로는 첫째, perm generation collection을 full gc때만 하는 문제가 있다. 즉, 클래스 언로딩을 full gc때만해서 자주 재배포가 발생하는 코드가 있는 경우 문제가 될 수 있다. 앞으로는 perm generation을 완전히 없애도록 JVM의 방향을 잡고 있기 때문에 당분간 이 문제는 해결하지 않을 것으로 보인다. 둘째, G1 GC에서 거대 객체(humongous object)라고 부르는 메모리 사용량이 큰 객체들...