JVM

클래스 로더는 JVM의 핵심 구성 요소 중 하나로, 자바 바이트코드로 구성된 .class 파일을 로드하고, 이를 런타임 데이터 영역의 메소드 영역에 배치하는 역할을 담당한다. 이 과정은 동적 로딩을 지원하며, 애플리케이션이 실행되는 도중에 필요한 클래스를 찾아 메모리에 적재한다.

클래스 로더는 계층 구조를 이루며 작동한다. 최상위에는 부트스트랩 클래스 로더가 있으며, 이는 JRE의 핵심 라이브러리(예: java.lang 패키지)를 로드한다. 그 다음으로 플랫폼 클래스 로더(자바 9 이전에는 익스텐션 클래스 로더)가 표준 확장 API를, 애플리케이션 클래스 로더가 사용자 애플리케이션의 클래스패스 상의 클래스를 로드한다. 이 계층 구조는 위임 모델을 따르는데, 클래스를 로드할 때 하위 로더는 상위 로더에 먼저 로드를 요청한다. 상위 로더에서 클래스를 찾지 못한 경우에만 하위 로더가 직접 클래스를 찾는다. 이 모델은 보안과 클래스의 일관성을 유지하는 데 기여한다.

클래스 로더의 주요 작업 단계는 로딩, 링킹, 초기화로 구분된다. 로딩 단계에서 바이너리 데이터를 읽어온다. 링킹 단계는 검증, 준비, 분석(옵션)의 세부 단계로 나뉘며, 클래스의 구조적 정확성을 확인하고 정적 필드에 메모리를 할당한다. 마지막으로 초기화 단계에서 정적 변수에 할당된 값과 정적 블록을 실행한다.

클래스 로더는 동일한 클래스를 서로 다른 로더로 중복 로드할 수 있으며, 이는 클래스 로더 네임스페이스를 형성한다. 이 특성은 자바 EE 애플리케이션 서버나 OSGi 프레임워크와 같이 모듈 간 격리가 필요한 환경에서 활용된다. 또한, 사용자 정의 클래스 로더를 구현하여 네트워크나 데이터베이스와 같은 비표준 소스에서 클래스를 동적으로 로드하는 것도 가능하다.

JVM의 런타임 데이터 영역은 프로그램 실행 중에 데이터를 저장하기 위해 사용되는 메모리 공간이다. 이 영역은 스레드별로 독립적으로 할당되는 영역과 모든 스레드가 공유하는 영역으로 구분된다.

스레드별로 생성되는 영역에는 PC 레지스터, JVM 스택, 네이티브 메서드 스택이 있다. PC 레지스터는 현재 실행 중인 명령어의 주소를 가리킨다. JVM 스택은 메서드 호출 시마다 프레임이 생성되고 제거되는 공간으로, 지역 변수, 중간 연산 결과, 메서드 호출 및 반환 정보를 저장한다. 네이티브 메서드 스택은 JNI를 통해 호출된 C/C++ 같은 네이티브 코드의 실행 정보를 관리한다.

모든 스레드가 공유하는 주요 영역은 힙과 메서드 영역이다. 힙은 객체 인스턴스와 배열이 생성되는 공간으로, 가비지 컬렉션의 주요 대상이 된다. 메서드 영역은 클래스 구조(런타임 상수 풀, 필드 및 메서드 정보, 정적 변수)와 같은 메타데이터를 저장한다. 이 영역은 JVM 구현체에 따라 퍼머넌트 제너레이션 또는 메타스페이스라고 불리기도 한다.

런타임 상수 풀은 메서드 영역의 일부로, 각 클래스 또는 인터페이스의 상수 정보를 가지고 있다. 여기에는 숫자 리터럴, 문자열 리터럴, 클래스 및 메서드에 대한 심볼릭 레퍼런스가 포함된다. 실행 엔진은 이 상수 풀을 참조하여 실제 메모리 주소를 연결한다.

실행 엔진은 JVM이 바이트코드를 실제 시스템에서 실행 가능한 기계어로 변환하고 수행하는 핵심 모듈이다. 주로 인터프리터, JIT 컴파일러, 가비지 컬렉터로 구성되며, 이들은 런타임 데이터 영역에 로드된 클래스의 바이트코드를 읽어 실행한다.

초기 실행 방식은 인터프리터에 의존한다. 인터프리터는 바이트코드를 한 줄씩 읽고 해석하여 즉시 실행하는데, 시작 속도는 빠르지만 반복적으로 같은 코드를 해석해야 하므로 상대적으로 최종 실행 성능은 낮은 편이다. 이를 보완하기 위해 현대 JVM은 적응형 최적화 기술을 사용하는 JIT 컴파일러를 도입했다. JIT 컴파일러는 프로그램 실행 중에 자주 사용되는 바이트코드 영역(핫스팟)을 식별하여 네이티브 기계어로 컴파일한다. 컴파일된 코드는 캐시에 저장되어 이후 같은 코드는 직접 실행되므로 인터프리터 모드보다 훨씬 빠른 성능을 제공한다.

실행 엔진의 또 다른 주요 구성 요소는 가비지 컬렉션을 수행하는 가비지 컬렉터다. 실행 엔진은 힙 메모리에서 객체를 생성하고 참조하는 작업을 관리하며, 더 이상 사용되지 않는 객체를 가비지 컬렉터가 자동으로 회수하여 메모리를 확보한다. 또한, 실행 엔진은 JNI를 통해 네이티브 메서드 라이브러리를 호출할 수 있다. 이를 통해 C/C++ 등으로 작성된 라이브러리를 사용하여 시스템 고유의 기능을 수행하거나 성능이 중요한 작업을 처리한다.

JNI는 자바 가상 머신 위에서 실행되는 자바 코드가 C, C++, 어셈블리어 등으로 작성된 네이티브 애플리케이션이나 라이브러리를 호출하고, 반대로 네이티브 코드가 자바 객체와 메서드를 조작할 수 있도록 하는 프로그래밍 프레임워크이다. 이는 자바 애플리케이션이 운영 체제의 특정 기능이나 레거시 코드, 성능이 중요한 저수준 작업에 접근해야 할 때 필수적인 역할을 한다.

JNI를 사용하기 위해서는 자바 측에서 native 키워드로 메서드를 선언하고, C 헤더 파일을 생성한 후 해당 선언에 맞는 네이티브 함수를 구현해야 한다. 구현된 네이티브 코드는 공유 라이브러리(예: Windows의 .dll, Linux의 .so)로 컴파일되며, 자바 코드에서는 System.loadLibrary()를 통해 로드된다. JNI는 복잡한 데이터 타입 변환과 메모리 관리를 요구하며, 잘못된 사용은 메모리 누수나 JVM 충돌을 초래할 수 있다.

네이티브 메서드 라이브러리는 JNI 인터페이스를 통해 호출되는 실제 네이티브 코드의 집합이다. 이 라이브러리들은 주로 플랫폼 의존적인 작업을 수행한다. 대표적인 예로는 자바 표준 라이브러리의 일부인 java.io, java.net 패키지의 내부 구현이 있으며, 그래픽 처리를 위한 AWT와 Swing의 저수준 컴포넌트도 네이티브 라이브러리에 의존한다[1].

JNI와 네이티브 메서드 라이브러리의 사용은 플랫폼 간 이식성을 저해하고 애플리케이션의 복잡성을 증가시키는 단점이 있다. 따라서 현대의 자바 개발에서는 순수 자바 라이브러리나 JNA와 같은 상위 레벨 추상화 도구를 우선적으로 고려하는 것이 일반적이다. 그러나 시스템 수준의 제어나 극한의 성능이 요구되는 특수한 경우에는 여전히 중요한 기술로 남아 있다.

힙은 JVM이 관리하는 메모리 영역 중 가비지 컬렉션의 대상이 되는 객체 인스턴스와 배열이 할당되는 공간이다. 모든 스레드가 공유하며, 애플리케이션이 실행되는 동안 동적으로 생성되는 객체의 생명주기를 관리한다. 힙의 크기는 -Xms(초기 힙 크기)와 -Xmx(최대 힙 크기) 같은 JVM 옵션으로 설정할 수 있으며, 필요에 따라 확장되거나 축소된다.

대부분의 현대 JVM 구현체는 객체의 생명주기와 특성에 따라 효율적인 메모리 관리와 가비지 컬렉션을 위해 힙을 여러 세대(Generation)로 나눈다. 이는 "대부분의 객체는 일찍 죽는다"는 약한 세대 가설에 기반한다. 주요 영역은 다음과 같다.

Young Generation에서 발생하는 Minor GC는 비교적 빈번하고 빠르게 수행된다. Eden 영역이 가득 차면 Minor GC가 트리거되어, 살아있는 객체는 하나의 Survivor 영역으로 이동시키고 Eden과 사용 중이던 Survivor 영역을 한꺼번에 정리한다. Survivor 영역 간의 객체 복사가 반복되며, 특정 임계값(예: 15회) 이상 생존한 객체는 Old Generation으로 승격된다. Old Generation이 가득 차면 더 오래 걸리는 Major GC(또는 Full GC)가 수행되어 전체 힙을 대상으로 메모리를 정리한다.

가비지 컬렉션 알고리즘은 할당된 힙 메모리에서 더 이상 사용되지 않는 객체를 식별하고 회수하는 방식을 정의한다. JVM 구현체는 다양한 GC 알고리즘을 제공하며, 애플리케이션의 성능 요구사항에 따라 선택할 수 있다. 주요 알고리즘은 처리 방식과 스톱 더 월드 발생 지점, 처리 대상 세대에 따라 구분된다.

세대별 가비지 컬렉션은 객체의 생존 기간에 따른 통계적 경향을 활용한다. 대부분의 객체는 생성 후 금사 사라지는 경향이 있으므로, 힙을 영 세대와 올드 세대로 나누어 관리한다. 영 세대에서는 빠르게 소멸하는 객체를 효율적으로 처리하기 위해 마이너 GC가 빈번히 발생하며, 일반적으로 카피 알고리즘이 사용된다. 올드 세대로 장기 생존한 객체가 이동하면, 여기서는 메이저 GC가 발생하며 마크-스위프-컴팩트 알고리즘이나 콘커런트 마크-스위프 알고리즘이 주로 사용된다.

주요 GC 알고리즘의 종류와 특징은 다음과 같다.

최신 저지연 GC 알고리즘인 ZGC와 Shenandoah GC는 애플리케이션 실행과 거의 동시에 모든 GC 작업을 수행하는 것을 목표로 한다. 이들은 수 테라바이트에 이르는 대용량 힙에서도 수 밀리초 미만의 짧은 스톱 더 월드 시간을 보장한다. 알고리즘 선택은 애플리케이션의 처리량, 최대 지연 시간 허용치, 사용 가능한 하드웨어 리소스 등에 따라 결정된다.

HotSpot은 오라클이 개발하고 유지 관리하는 가장 널리 사용되는 JVM 구현체이다. 원래는 Sun Microsystems의 자회사인 Longview Technologies[2]에서 개발되었으며, 1999년에 자바 1.3 버전부터 자바 표준 JVM의 참조 구현체로 채택되었다. 이름의 유래는 프로그램 실행 시간의 대부분이 소수의 핵심 코드에 집중된다는 '핫스팟(Hot Spot)' 최적화 개념에서 비롯되었다.

이 구현체의 가장 큰 특징은 적응형(Adaptive) 최적화 기술을 사용한다는 점이다. HotSpot은 애플리케이션 실행 초기에는 바이트코드를 인터프리터 방식으로 실행하면서 성능 프로파일링 데이터를 수집한다. 자주 실행되는 '핫'한 메서드를 식별하면, 그 부분을 실시간으로 네이티브 코드로 컴파일하는 JIT 컴파일을 수행한다. 이 방식은 시작 속도와 장기 실행 성능 사이의 균형을 효과적으로 맞춘다.

HotSpot JVM은 두 가지 주요 운영 모드를 제공한다. 클라이언트 모드(Client VM)는 GUI 애플리케이션과 같이 빠른 시작 시간과 적은 메모리 사용이 중요한 환경에 적합하다. 서버 모드(Server VM)는 더 공격적인 최적화와 대용량 힙 메모리를 사용하여 장기간 실행되는 서버 애플리케이션의 최대 처리량을 극대화하도록 설계되었다.

주요 구성 요소와 특징은 다음과 같다.

HotSpot은 OpenJDK 프로젝트의 핵심 부분으로, 소스 코드가 공개되어 있다. 이는 자바 생태계의 표준 플랫폼으로 자리 잡았으며, 지속적인 발전을 통해 새로운 가비지 컬렉션 알고리즘과 최적화 기술을 도입하고 있다.

OpenJ9은 이클립스 재단의 이클립스 오픈J9 프로젝트에서 개발 및 관리되는 오픈 소스 JVM 구현체이다. 원래 IBM이 자사의 상용 제품인 IBM J9 가상 머신을 기반으로 2017년에 오픈 소스로 공개한 것이 그 기원이다. 이후 이클립스 재단으로 기증되어 커뮤니티 중심의 개발이 이루어지고 있다.

OpenJ9의 주요 설계 목표는 빠른 시작 시간, 낮은 메모리 사용량, 그리고 예측 가능한 성능에 있다. 이는 특히 클라우드 컴퓨팅 및 컨테이너 환경에서 중요한 특성으로 작용한다. OpenJ9은 Ahead-of-Time 컴파일과 같은 기술을 활용하여 애플리케이션 시작 속도를 크게 개선하고, 공유 클래스 캐시 기능을 통해 여러 JVM 인스턴스가 메타데이터를 공유하여 메모리 사용 효율을 높인다.

OpenJ9은 HotSpot과 함께 OpenJDK 빌드의 주요 런타임 엔진 옵션으로 자리 잡았다. 사용자는 동일한 JDK 클래스 라이브러리(예: OpenJDK의 jdk)와 OpenJ9 VM을 조합하여 사용할 수 있다. 이는 개발자와 운영자에게 애플리케이션 요구사항에 맞는 JVM을 선택할 수 있는 유연성을 제공한다. 성능 튜닝 측면에서는 HotSpot과 다른 고유의 JVM 명령행 옵션 세트를 가지며, IBM에서 제공하던 모니터링 및 진단 도구의 상당 부분이 오픈 소스 생태계에 통합되었다.

GraalVM은 오라클이 주도하여 개발한 고성능 폴리글랏 가상 머신이다. 기존 JVM이 주로 자바 언어를 실행하는 데 특화된 반면, GraalVM은 자바, 자바스크립트, 파이썬, 루비, R 언어 등 여러 언어를 효율적으로 실행할 수 있는 범용 실행 환경을 제공하는 것이 핵심 목표이다.

GraalVM의 핵심 구성 요소는 Graal 컴파일러와 Truffle 언어 구현 프레임워크이다. Graal 컴파일러는 JIT 컴파일 방식의 고급 컴파일러로, HotSpot JVM의 C2 컴파일러를 대체할 수 있는 성능을 지닌다. Truffle은 새로운 프로그래밍 언어를 위한 인터프리터를 쉽게 구현할 수 있게 해주는 프레임워크로, Truffle로 작성된 언어 구현체는 Graal 컴파일러에 의해 자동으로 고성능의 네이티브 코드로 최적화되는 이점을 가진다[3].

GraalVM은 크게 두 가지 에디션으로 제공된다. 커뮤니티 에디션은 오픈 소스이며, 엔터프라이즈 에디션은 상용 제품으로 추가적인 성능 최적화와 관리 기능을 포함한다. 또한 GraalVM의 중요한 기능 중 하나는 네이티브 이미지 생성 도구이다. 이 도구는 자바 애플리케이션을 사전에 네이티브 기계어로 컴파일하여 독립 실행형 실행 파일로 만들어주며, 이를 통해 애플리케이션의 시작 속도를 크게 향상시키고 메모리 사용량을 줄일 수 있다.

GraalVM은 마이크로서비스, 클라우드 네이티브 애플리케이션, 서버리스 컴퓨팅 환경에서 빠른 시작과 높은 효율성이 요구되는 곳에 특히 적합하다. 기존 자바 생태계의 호환성을 유지하면서도 현대적 애플리케이션의 요구사항을 충족시키는 차세대 플랫폼으로 주목받고 있다.

JVM 옵션은 자바 가상 머신의 동작을 제어하고 성능을 튜닝하기 위한 명령줄 매개변수이다. 크게 표준 옵션, 비표준 옵션, 고급 옵션으로 구분된다. 표준 옵션(-client, -server, -version 등)은 모든 JVM 구현체에서 보장되며, 비표준 옵션(-X로 시작)과 고급 옵션(-XX로 시작)은 구현체에 따라 다르게 동작하거나 존재하지 않을 수 있다. 이러한 옵션들은 애플리케이션 시작 시 java 명령어와 함께 지정하여 힙 크기, 가비지 컬렉터 종류, JIT 컴파일 동작 등을 세밀하게 조정한다.

가장 일반적으로 사용되는 옵션들은 메모리 할당과 관련된다. 예를 들어, 초기 힙 크기와 최대 힙 크기는 -Xms와 -Xmx 옵션으로 설정한다. -Xms512m -Xmx2g는 JVM이 시작될 때 512MB의 힙을 확보하고, 필요 시 최대 2GB까지 확장할 수 있도록 지시한다. 사용할 가비지 컬렉션 알고리즘은 -XX:+UseG1GC(G1 GC 사용) 또는 -XX:+UseZGC(ZGC 사용)와 같은 -XX 옵션으로 선택한다. 로깅 및 모니터링을 위해 -XX:+PrintGCDetails(상세 GC 로그 출력)나 -XX:+HeapDumpOnOutOfMemoryError(OutOfMemoryError 발생 시 힙 덤프 생성) 같은 진단 옵션도 자주 활용된다.

옵션 적용은 애플리케이션의 부하 특성과 하드웨어 환경에 맞춰 실험적으로 진행된다. 부적절한 옵션 설정은 성능 저하나 불안정성을 초래할 수 있으므로, 변경 사항은 프로파일링 도구를 통해 성능 영향을 반드시 측정하고 검증해야 한다. 또한, 특정 JVM 버전이나 벤더(예: HotSpot, OpenJ9)에 종속적인 옵션은 마이그레이션 시 호환성 문제를 일으킬 수 있다는 점에 유의한다.

JVM의 성능을 분석하고 병목 현상을 식별하기 위해 다양한 프로파일링 도구가 사용된다. 이 도구들은 CPU 사용률, 메모리 할당, 스레드 상태, 가비지 컬렉션 활동, 메서드 실행 시간 등을 상세히 측정하여 애플리케이션의 런타임 동작을 가시화한다.

주요 프로파일링 도구는 다음과 같이 분류할 수 있다.

효율적인 프로파일링을 위해서는 목표에 맞는 도구를 선택하고 측정 오버헤드를 고려해야 한다. CPU 병목 분석에는 샘플링 기반 프로파일러를, 메모리 누수 탐지에는 힙 히스토그램과 객체 참조 트리를 분석하는 도구를 주로 사용한다. 또한, 프로덕션 환경에서는 Java Flight Recorder (JFR)와 같은 저오버헤드 이벤트 기반의 프로파일링 기술을 활용하여 성능 문제를 진단하는 것이 일반적이다.