Java 서버가 시작 직후에는 느리다가 같은 요청을 반복하면 빨라집니다. 인터프리터와 JIT가 어떤 역할을 하며 성능 측정에서 예열을 왜 구분해야 하나요?

Java 소스 코드는 먼저 컴파일러에 의해 JVM이 이해하는 바이트코드가 담긴 class 파일로 변환됩니다. JVM은 이 바이트코드의 동작 의미를 실행하는 추상 머신이며, 명세가 반드시 한 명령씩 해석하라고 정하는 것은 아닙니다. 실제 구현은 처음에는 인터프리터 방식으로 메서드나 바이트코드를 실행할 수 있고, 자주 호출되는 코드의 실행 정보를 모아 JIT(Just-In-Time) 컴파일러가 네이티브 기계어로 바꿔 실행할 수 있습니다. 따라서 ‘JVM은 인터프리터다’ 또는 ‘모든 Java 코드는 항상 JIT된다’라고 단정하면 부정확합니다. JIT 사용 여부와 컴파일 시점, 임계값은 JVM 구현과 옵션에 따라 달라집니다.

바이트코드와 구현 전략

예열(warm-up)은 프로그램 시작 직후와 충분히 실행된 뒤의 조건이 다르다는 뜻입니다. 초반에는 클래스 로딩·검증·링킹·초기화, 메서드 호출과 JIT 컴파일 비용이 함께 나타납니다. 반대로 JIT가 실제 타입 분포와 분기 빈도를 관찰하면 인라이닝 같은 최적화를 적용할 수 있고, 나중에 가정이 깨지면 최적화를 되돌리는 디옵티마이제이션도 일어날 수 있습니다. 그래서 짧은 한 번의 실행 시간만 보고 Java 성능을 판단하면 준비 비용을 측정한 결과일 수 있습니다.

예열을 포함한 측정

성능을 비교할 때는 목표 JVM과 옵션, Java 버전을 고정하고, 동일한 입력으로 준비 구간과 안정 구간을 나누어 여러 번 측정하겠습니다. 처리량뿐 아니라 p95·p99 지연, 컴파일 스레드의 CPU 사용량, 메모리와 코드 캐시도 함께 봐야 합니다. 초기 응답 시간이 중요한 짧은 CLI라면 예열 비용을 줄이는 방식이 중요하고, 오래 실행되는 서버라면 충분한 예열 뒤의 안정적인 처리량과 재컴파일로 인한 지연을 기준으로 판단하는 편이 맞습니다. JVM 명세 자체는 특정 JIT 정책을 보장하지 않으므로, 배포 환경에서 실제 JVM의 동작을 검증해야 합니다.

선택 기준과 검증

예열된 서버 결과가 좋아도 롤링 배포나 오토스케일 직후에는 여러 인스턴스가 동시에 클래스 로딩과 JIT 컴파일을 수행해 p99가 악화될 수 있습니다. 반대로 고정된 예열 입력은 운영 분기와 다른 최적화를 만들 수 있습니다. cold start, 예열 곡선, steady state, 재시작 상황을 나누고 JFR·컴파일 로그·GC 로그를 요청 지연과 함께 보겠습니다.

HotSpot의 계층형 컴파일은 빠른 초기 실행과 더 비싼 최적화 사이에서 단계적으로 비용을 지불할 수 있습니다. 자주 호출된 메서드나 오래 반복되는 루프가 대상이 되며, 실행 중 루프를 컴파일된 코드로 옮기는 OSR도 있을 수 있습니다. 어떤 JVM이든 같은 임계값과 단계가 있다는 뜻은 아니므로 운영 배포판의 컴파일 로그를 근거로 설명하겠습니다.

한 호출 지점에서 실제 타입이 거의 하나라면 가상 호출도 특정 구현으로 인라인할 수 있습니다. 이후 다른 타입이 들어와 가정이 깨지면 deoptimization이 필요할 수 있으므로 예열 입력이 운영 분포를 닮아야 합니다. 마이크로벤치마크에서는 결과를 사용하지 않아 계산이 제거되거나 상수가 미리 계산되는 함정도 있습니다. JMH 같은 검증된 도구와 여러 프로세스 실행으로 예열·측정·최적화 제거를 구분하고, 실제 요청 경로에서도 이득을 다시 확인하겠습니다.