윤경구의 Log on Java

정말 오래간만에 자바 관련한 블로깅입니다. 불편한 사람들이 있을 것 같아서 정보 공유 차원에서 현재까지 파악한 이슈를 남깁니다. macOS Catalina(10.15.3) 버전부터 JDK의 System.loadLibrary를 통한 dylib 파일 로드가 실패합니다. 이와 관련해서는 크게 두 가지 문제가 관련되어 있습니다. 1. System.loadLibrary 버그 공식 JDK 관련 이슈는 다음 이슈에서 볼 수 있습니다. Java Bug System :  System.loadLibrary fails on Big Sur for libraries hidden from filesystem GitHub :  System.loadLibrary fails on Big Sur for libraries hidden from filesystem System.loadLibrary()를 통한 경로 찾기가 실패하는가 하고 여러 시도를 해보면 곧 System.load()를 통해 dylib 파일을 직접 읽어도 제대로 동작하지 않는다는 것을 알게 될 것입니다. JDK 라이브러리 로딩 버그의 원인(아직 미해결)을 옮겨봅니다. System.loadLibrary 실패 원인 문제 설명:  OSX Big Sur no longer ships with copies of the libraries on the filesystem and therefore attempts to load a native library via System.loadLibrary no longer works. 애플 페이지 내용: New in macOS Big Sur 11.0.1, the system ships with a built-in dynamic linker cache of all system-provided libraries. As part of this change, copies of dynamic libraries are no longer present on the filesystem. C...

IBM JDK를 사용할 때 (gc policy는 보통 gencon) 물리 메모리가 많이 남아있는 경우에도 native out of memory (NOOM)가 발생하는 경우가 있다. NOOM이 발생하지 않았더라도 global gc 가 자주 발생하여 성능에 영향을 주기도 한다. verbose gc 로그를 보면 sys-start reason="native out of memory" 라는 이유로 global gc가  실행되는 것을 볼 수 있다. 이렇게 global gc가 자주 발생하면 자바의 가장 큰 골치거리인 Stop-The-World 현상이 발생하여 순간적으로 멈춰서게 되어 매우 불안정하게 되는데 이 문제의 원인은 무엇인지 알아보자. 이 문제가 발생하는 경우는 IBM JDK (버전 6 이후)를 사용하고 64비트 JVM, 전체 Java Heap 크기를 4GB 이상 25GB 이하로 줬을 때이다. -Xmx 값이 4GB~25GB이면 IBM 64bit JVM은 기본값으로 -XcompressedRefs 옵션을 켠 것과 동일한 방식으로 동작한다. 자바의 객체들은 JVM 내부에서 2-word 크기의 헤더를 가지는데 32bit JVM에서는 2-word는 8byte이며, 64bit JVM에서는 2-word가 16byte가 된다. 64bit 방식으로 자바 객체를 addressing하게 되면 사용할 수 있는 메모리 영역은 훨씬 더 커지겠지만 메모리를 과다 사용하고 OS의 page cache fault 등의 문제로 성능적으로도 느려질 수밖에 없다. 그래서 64bit JVM에서도 32bit 방식으로 자바 객체 주소를 addressing하는 방식이 바로 compressed reference라는 개념이다. compressed reference 방식으로는 최대 32GB까지 주소를 나타낼 수 있다. 이 경우 Java Heap에 있는 자바 객체들에 대한 주소는 shift 연산을 통해 32bit 주소의 한계인 4GB를 넘어서 최대 32GB까지 참조할 ...