Java Compact Object Headers 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.

Java Compact Object Headers는 HotSpot JVM의 객체 헤더를 더 작게 쓰기 위한 JDK 25 기능입니다. 핵심은 64비트 환경에서 객체마다 붙는 메타데이터 공간을 줄여 heap 사용량과 GC 부담을 낮출 수 있다는 점입니다.

다만 JDK 25에서 이 기능은 제품 기능(product feature)이 되었을 뿐, 기본 객체 헤더 레이아웃은 아닙니다. 운영 서비스에 적용할 때는 JDK 버전, JVM 옵션, 사용 중인 라이브러리의 JVM 내부 의존 여부, 성능 측정 결과를 같이 봐야 합니다.

Compact Object Headers는 무엇인가

Java 객체는 필드 값만 heap에 저장하지 않습니다. HotSpot JVM은 객체의 클래스 정보, 잠금 상태, GC age, identity hash code 같은 런타임 메타데이터를 객체 헤더에 둡니다. 이 헤더 크기는 객체 종류와 관계없이 붙기 때문에 작은 객체가 많은 애플리케이션에서는 전체 heap 사용량에 영향을 줍니다.

OpenJDK JEP 450은 기존 64비트 HotSpot JVM 객체 헤더가 설정에 따라 96비트 또는 128비트가 될 수 있고, Compact Object Headers가 이를 64비트로 줄이는 실험 기능이라고 설명합니다. JDK 25의 JEP 519는 이 기능을 실험 기능에서 제품 기능으로 바꿨습니다.

JDK 25에서 무엇이 달라졌나

JDK 24에서는 Compact Object Headers를 켜려면 실험 기능 잠금 해제 옵션이 필요했습니다.

java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders ...

JDK 25에서는 -XX:+UnlockExperimentalVMOptions 없이 다음처럼 켤 수 있습니다.

java -XX:+UseCompactObjectHeaders ...

중요한 점은 이 옵션이 기본값이 아니라는 것입니다. Oracle JDK 25 릴리스 노트도 UseCompactObjectHeaders가 product option이 되었지만 이 릴리스에서는 기본 비활성 상태라고 설명합니다. 따라서 JDK 25로 올렸다고 해서 자동으로 객체 헤더가 바뀌는 것은 아닙니다.

왜 heap 사용량에 영향을 주나

객체 헤더는 모든 객체에 반복해서 붙는 고정 비용입니다. 예를 들어 작은 DTO, 컬렉션 노드, 문자열 주변 객체, 캐시 엔트리처럼 작은 객체가 많이 생기는 서비스에서는 객체 하나의 헤더 몇 바이트 차이가 전체 live data 크기에 누적될 수 있습니다.

JEP 450은 Java 프로그램의 많은 workload에서 평균 객체 크기가 32~64바이트인 경우가 있고, live data의 20% 이상이 객체 헤더만으로 차지될 수 있다고 설명합니다. 이 수치는 모든 서비스에 그대로 적용되는 보장은 아니지만, 작은 객체가 많은 서비스에서 측정해볼 이유는 충분합니다.

적용 전 확인할 기준

Compact Object Headers는 단순히 켜면 항상 빨라지는 옵션으로 보면 안 됩니다. 적용 판단은 다음 기준으로 나누는 편이 안전합니다.

확인 기준	봐야 할 내용	판단 포인트
JDK 버전	JDK 25 이상인지 확인	JDK 24에서는 실험 기능 옵션이 필요했습니다.
객체 구성	작은 객체가 많은 workload인지 확인	큰 byte 배열 위주라면 효과가 작을 수 있습니다.
GC 지표	heap 사용량, GC 횟수, pause time 비교	메모리 절감과 지연 시간 변화를 함께 봐야 합니다.
호환성	JVM 내부 구조에 의존하는 agent나 native 도구 사용 여부	프로파일러, 모니터링 agent, JNI 코드가 있다면 staging 검증이 필요합니다.
CDS 사용	custom runtime image 또는 CDS archive 사용 여부	옵션 조합에 맞는 archive 생성이 필요할 수 있습니다.

 

 

언제 검토할 만한가

첫째, memory footprint가 비용이나 안정성에 직접 영향을 주는 서버입니다. 같은 heap 크기에서 더 많은 객체를 담거나, 같은 workload를 더 작은 heap으로 처리할 가능성을 확인할 수 있습니다.

둘째, GC 압박이 높은 서비스입니다. 객체 헤더가 줄어 live data가 줄면 GC가 다루는 데이터량도 줄 수 있습니다. 다만 실제 pause time과 throughput은 collector, allocation rate, 객체 생존 패턴에 따라 달라지므로 기존 지표와 같은 조건에서 비교해야 합니다.

셋째, JDK 25 도입을 이미 검토하고 있는 서비스입니다. JDK 업그레이드와 별도로 옵션 하나만 바꿔 측정할 수 있으므로, 업그레이드 검증 항목에 포함하기 좋습니다.

언제 보류하는 편이 나은가

JDK 21 같은 장기 지원 버전에 고정된 운영 환경이라면 JDK 25 기능을 전제로 한 적용은 어렵습니다. 일부 벤더가 backport를 제공할 수는 있지만, 그 경우에도 해당 배포판의 문서와 지원 범위를 따로 확인해야 합니다.

JVM 내부 객체 레이아웃에 민감한 agent, JNI 코드, 비표준 진단 도구를 많이 쓰는 환경도 바로 적용하기보다 staging에서 충분히 확인하는 편이 안전합니다. Java 표준 API만 사용하는 일반 애플리케이션이라도 운영 옵션 변경은 측정 없이 판단하지 않는 것이 좋습니다.

측정은 어떻게 시작하나

가장 단순한 방식은 같은 JDK 25 빌드에서 옵션만 바꿔 비교하는 것입니다. 같은 트래픽 재현, 같은 heap 설정, 같은 GC 설정으로 baseline과 실험군을 나눕니다.

# baseline
java -Xms2g -Xmx2g -jar app.jar

# compact object headers
java -Xms2g -Xmx2g -XX:+UseCompactObjectHeaders -jar app.jar

비교할 값은 최소한 세 가지입니다. 최대 heap 사용량, GC 횟수와 pause time, 그리고 요청 처리 지연 시간입니다. 메모리는 줄었지만 지연 시간이 나빠지는 경우도 있을 수 있으므로 한 가지 지표만으로 결론을 내리면 안 됩니다.

CDS와 custom image를 쓴다면

Oracle JDK 25 릴리스 노트는 -XX:+UseCompactObjectHeaders를 custom image와 함께 쓰는 경우 추가 CDS archive 생성 절차가 필요할 수 있다고 설명합니다. jlink로 만든 image에서 같은 옵션을 켠 상태로 -Xshare:dump를 실행해 해당 구성에 맞는 archive를 만들 수 있습니다.

<image>/bin/java -XX:+UseCompactObjectHeaders -Xshare:dump

CDS를 쓰지 않는 일반 실행이라면 이 절차가 항상 필요한 것은 아닙니다. 하지만 startup 성능을 중요하게 보고 custom runtime image를 쓰는 환경이라면 이 항목을 배포 체크리스트에 넣어야 합니다.

정리

Java Compact Object Headers는 JDK 25에서 실험 기능을 벗어난 HotSpot JVM 기능입니다. 작은 객체가 많은 애플리케이션에서는 heap footprint와 GC 압박을 줄일 수 있는 후보가 됩니다.

실무 기준은 명확합니다. JDK 25 이상에서 -XX:+UseCompactObjectHeaders로 켜고, 같은 조건의 성능 테스트로 heap 사용량, GC, 지연 시간을 비교합니다. 기본값이 아니므로 자동 적용을 기대하지 말고, agent와 CDS 같은 주변 구성까지 함께 검증해야 합니다.

참고 자료

• OpenJDK JEP 519: Compact Object Headers
• OpenJDK JEP 450: Compact Object Headers (Experimental)
• OpenJDK JDK 25 release page
• Oracle JDK 25 Release Notes